Stan Ryckman <stanr(_at_)sunspot(_dot_)tiac(_dot_)net> writes:
At 12:19 PM 3/27/99 -0600, Philip Guenther wrote:
...
I've stared at the code and after trying some stuff, I can say that
it's either a bug in gcc, gas, or the iX86 FPU itself.
No bug this... it's a feature of the C language! Been there before :-)
You're seeing the effect of a sentence in the Standard: "The values of
floating operands and of the results of floating expressions may be
represented in greater precision and range than that required by the
type; the types are not changed thereby."
Dang, I'm out of ketchup. I guess I'll have to eat my words plain:
You are correct -- the bug is in procmail's invocation of
implementation defined behavior.
To be specific, but working from memory so this could be a buggy
description :-), the X86 uses 80-bit floating point registers to do
calculations, which for "double" get stored into 64-bit memory locations.
Thus, truncation occurs whenever storing occurs; when results persist in
a register, the 80 bit value there may well be different than if stored
into a 64-bit number and then reloaded.
You can trust your memory: you have the sizes correct.
...
I would seriously consider declaring nweight to be "volatile double" here
as well, to prevent an optimizer from repeating what happened with the
previous code.
Good thought. I've done so.
Philip Guenther