> It turns out that there's another nasty in there, related to floating
> point stuff.  I've reproduced the problem on two different Intel 486
> systems, a Digital PC with a patch for the above bug installed and a
> Compaq with no patches whatsoever; just straight NetBSD-current with
> the x87-dependent lines in the libm Makefile enabled.
> 
> The way I discovered this was that I compiled ACM (the air combat
> flight simulator) at "-O2", and it simply didn't work -- it just
> spewed out error messages.  With "-O" it started working, but it would
> crash a lot, until I recompiled libm with "-O" and installed it.  ACM
> has worked great since then.
> 
> Could someone "in the know" check whether this might be related to
> something particular to the NetBSD implementation, and otherwise maybe
> report it to the GCC folks through proper channels?

The problem with paranoia is most likely do to the fact that the i387
(and the FPUs on i[456]86 CPUs) registers are 80 bits and doubles are
64 bits.  Depending on when values are loaded/stored from FPU
registers, you can get slightly different results.  With some
programs, the differences are significant.

The last time I looked into this, I think I decided that the current
behavior still conforms to Standard C.  I've read a proposal for the
next C standard that enables to programmer to have more control over
floating point behavior.  

The gcc maintainers know of the excess precision problem, and the
-ffloat-store flag has been provided that minimizes the effect.  I
suspect that nothing more will be done until the next C standard is
ready.

Please try compiling with -ffloat -store and see if your problems 
are resolved.

	--jtc