From owner-freebsd-bugs  Thu Jun  8 23:26:59 1995
Return-Path: bugs-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id XAA16003
          for bugs-outgoing; Thu, 8 Jun 1995 23:26:59 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA15997
          for <bugs@FreeBSD.org>; Thu, 8 Jun 1995 23:26:54 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA20634; Fri, 9 Jun 1995 16:25:34 +1000
Date: Fri, 9 Jun 1995 16:25:34 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199506090625.QAA20634@godzilla.zeta.org.au>
To: bugs@FreeBSD.org, mal@algonet.se
Subject: Re: Bogus (?) SIGFPE's from divide by zero
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

>I don't know what the standards say, but other systems (at least SunOS)
>do not issue floating point exceptions on divide by zero. Bug in FreeBSD?

Standard C: result is undefined.  Sometimes the result is to send mail
            to bugs@freebsd.org :-)
POSIX: same as Standard C
IEEE: default is to record the exception but not trap on it
IBCS2: SIGFPE (at least according to (a comment in) 386BSD-0.0)

FreeBSD: IBCS2
Right: IEEE

FreeBSD conforms to Standard C here.  However, libm divides by zero on
purpose to generate IEEE exceptions.  This and other generation of IEEE
exceptions in libm makes libm nonconformant because the IEEE exceptions
generate SIGFPE's.

>(The constant divisions are replaced by constants by gcc, I suppose)

This is another bug.  It is OK for Standard C (the behaviour is undefined)
but not for IEEE.  In particular, it breaks the generation of IEEE
exceptions in libm.  The side effects are lost when the calculations
are done at compile time.  I believe Sun's compilers are more careful
than gcc here.

Bruce