*BSD News Article 8656


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: [386bsd] instlling fpu results in floating exceptions
Message-ID: <1992Dec8.170451.20362@runx.oz.au>
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
References: <bdES02Kd2dLZ01@JUTS.ccc.amdahl.com> <1fslq7INN3ub@tricky.wft.stack.urc.tue.nl>
Date: Tue, 8 Dec 92 17:04:51 GMT
Lines: 34

In article <1fslq7INN3ub@tricky.wft.stack.urc.tue.nl> jim@shark.wft.stack.urc.tue.nl (Jim Rump) writes:
>Gary A Browning (gab10@griffincd.amdahl.com) wrote:
>: 
>: For me, the Signal 6 problem with cc1 and g++ turned out to be an invalid
>: constant in the include file math.h.   The value of HUGE_VAL is quite a bit
>: too huge.  They have alreay fixed this in newer releases.  gcc 2.1 reported
>: a message (and then blew up).
>: 
>: In math.h, HUGE_VAL get defined to 1e500.  It works if you set it to
>: 1.7976931348623157E+308.  There are also a few suspects in float.h.
>: If you get further problems, try isolating the offending source code and then
>: change the defines.

I think that the bug is on those systems that do NOT get the signal.  The
problem with HUGE_VAL is real, but cc1 is too big to debug.  Try the following
program:

#include <stdlib.h>
main() { (void) atof("1e500"); sleep(2); }; }

You should get a SIGFPE from inside atof when atof causes an overflow.
Try it again without the sleep().  The sleep() is to avoid the kernel bug
that delays the delivery of asynchronous signals (floating point errors
are really synchronous but IRQ13 reports them asynchronously).  Try it
again after adding a signal handler for the SIGFPE.  Caught signals are
handled synchronously in most cases (unless the IRQ13 for them is nested
inside another interrupt or trap).

To calculate HUGE_VAL, cc1 just does atof("1e500").  atof is not supposed
to overflow but it does.  In this case it is supposed to return HUGE_VAL
(:-) and set errno to ERANGE.  cc1 apparently does not attempt to recover
from this exception.  It just aborts (signal 6).
-- 
Bruce Evans  (bde@runx.oz.au)