Date: Tue, 15 Jul 1997 07:50:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-ports Subject: Re: ports/4093: ports Oleo problem Message-ID: <199707151450.HAA01528@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/4093; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: FreeBSD-gnats-submit@FreeBSD.ORG, mutoh@info.nara-k.ac.jp Cc: Subject: Re: ports/4093: ports Oleo problem Date: Wed, 16 Jul 1997 00:41:35 +1000 >>Description: > In FreeBSD, "1./0." becomes infinity without calling function, This is a bug in gcc. 1./0. should be evaluated at runtime, giving the result infinity and setting the IEEE exception flags or causing a SIGFPE, but gcc evaluates it at compile time, giving the result infinitiy and NOT setting the IEEE exception flags. > but it becomes "1" with calling function. I think this is a bug in oleo. Dividing by 0 gives undefined behaviour in ANSI C, so some extension of ANSI C must be used to get defined behaviour. The actual (default) behaviour under FreeBSD is to deliver a SIGFPE. Ignoring the SIGFPE doesn't fix the problem. It gives undefined behaviour in ANSI C and under FreeBSD. The actual behaviour for x/0. under FreeBSD is to give the result x and push `0.' onto the FPU stack. The stack garbage may cause problems later. > Using oleo's function divide, the value "#INFINITY" becomes "1". > So 1./1. in a cell under oleo becomes be equal to "#INFINITY". This seems backwards. 1./1. should not cause any ininities. The port probably needs to use fpsetmask(0) to get defined (IEEE default) behaviour. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707151450.HAA01528>