Re: netbsd build update

[Jason Stover]

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 Makefile.am (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) 
>     {
>     #if HAVE_FEHOLDEXCEPT
>       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
> is, is HAVE_FEHOLDEXCEPT or both HAVE___SETFPUCW and _FPU_IEEE
> 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.

-Jason