[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netbsd build update

From: Jason Stover
Subject: Re: netbsd build update
Date: Thu, 18 May 2006 13:03:25 -0400
User-agent: Mutt/1.5.10i

On Wed, May 17, 2006 at 08:08:42PM -0700, Ben Pfaff wrote:
> Jason Stover <address@hidden> writes:
> > Short answer: The alpha chip does not comply entirely with ieee 754.
> > The -mieee option to gcc fixes the problem. Maybe this option should be
> > added conditionally in (or wherever such things go).
> The problem is a floating point exception (FPE), right?  (Before,
> I thought it was a segmentation fault, but I guess I
> misunderstood.)  I'd expect that increased IEEE compliance would
> only prevent an FPE if it prevented, say, underflow by instead
> resulting in a denormal.  If that's the case, then an underflow
> from a denormal to zero would still, presumably, cause an FPE and
> we'd only be papering over the problem, not curing.
> I do think that -mieee is a good idea, but I think we should look
> for a secondary problem too.  Here is one idea: PSPP tries to
> turn off FPEs entirely, in fpu_init() in main.c:
>     static void
>     fpu_init (void) 
>     {
>       fenv_t foo;
>       feholdexcept (&foo);
>     #elif HAVE___SETFPUCW && defined(_FPU_IEEE)
>       __setfpucw (_FPU_IEEE);
>     #endif
>     }
> Does NetBSD support either of the approaches we try there?  That
> defined when that function is compiled?  If not, then we should
> find out how we turn off FPEs on NetBSD and add that to the
> possibilities.  (We should possibly warn about this at configure
> time, too.)

None of these seem to be defined on NetBSD. I couldn't see any of them
in /usr/include, and adding an assert(0) in the #if and #elif
statements above didn't cause a failure.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]