Re: netbsd build update

[Jason Stover]

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).

Longer answer:

The problem is on line 179:

     d_power *= d;

d_power is about -2.9e306, no problem for ieee floating
point arithmetic. But when the next line

      m->d2 += d_power * weight;

tries to add weight (which is 1), we get the floating point
exception. I don't know what is happening on the chip, but
it may be something like an attempt to turn the exponent
of 1e0 into 0.0000...1e306 before multiplying, which won't work
since there are only 52 bits for the manitssa, not enough to
write 1e0 with 306 as an exponent.

The gcc manual says this:

 `-mieee'
     The Alpha architecture implements floating-point hardware
     optimized for maximum performance.  It is mostly compliant with
     the IEEE floating point standard.  However, for full compliance,
     software assistance is required.  This option generates code fully
     IEEE compliant code _except_ that the INEXACT-FLAG is not
     maintained (see below).  If this option is turned on, the
     preprocessor macro `_IEEE_FP' is defined during compilation.  The
     resulting code is less efficient but is able to correctly support
     denormalized numbers and exceptional IEEE values such as
     not-a-number and plus/minus infinity.  Other Alpha compilers call
     this option `-ieee_with_no_inexact'.

I gave this flag to configure, and it worked fine.

-Jason

On Wed, May 17, 2006 at 12:43:16PM +0800, John Darrington wrote:
> On Tue, May 16, 2006 at 11:06:28AM -0400, Jason Stover wrote:
>      
>      (gdb) bt
>      #0  moments_pass_two (m=0x120122480, value=0, weight=1)
>          at src/math/moments.c:179
>      #1  0x0000000120036678 in calc_descriptives (first=0x120122480, 
>          cf=0x120122600, dsc_=0x1201223b8) at 
> src/language/stats/descriptives.c:795
> 
> The interesting thing here, is that the "m" argument of frame 0 is the
> same address as the "first" argument of frame 1.  They shouldn't
> be. They are completely different animals.
> 
> 
> However, like Ben says, I wouldn't give too much credence to this,
> until I see it without optimisation.
> 
> J'
> 
> -- 
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://pgp.mit.edu or any PGP keyserver for public key.
> 
>