From owner-freebsd-ports Tue Jul 15 07:50:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA01549 for ports-outgoing; Tue, 15 Jul 1997 07:50:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA01528; Tue, 15 Jul 1997 07:50:02 -0700 (PDT) Date: Tue, 15 Jul 1997 07:50:02 -0700 (PDT) Message-Id: <199707151450.HAA01528@hub.freebsd.org> To: freebsd-ports Cc: From: Bruce Evans Subject: Re: ports/4093: ports Oleo problem Reply-To: Bruce Evans Sender: owner-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR ports/4093; it has been noted by GNATS. From: Bruce Evans 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