> This might explain a problem I am currently seeing.
> In an application where we use lots of double precision math and have
> some very touchy thresholds, if we compile with debug turned on and
> low optimization we get a different results than with debug turned off
> and high optimization.
> Is it possible that, with super scalar processing, the order of
> calculations between debug compile and high-optimization compile would
> cause some values to be placed back into memory instead of being
> stored in registers and thus round from 80 bits to 64 in a different
> order with the two compiles?
> We use P4 Xeon's and gcc on Linux.
This is indeed _very_ likely.
However, setting the precision control bits to double will avoid nearly
all such "problems", except those that are caused by the extended
exponent range of x86:
In some case where a regular double would cause underflow, x86 will keep
a full precision mantissa until the value is stored to memory, when
double rounding will occur again.
OTOH, by doing everyting in extended precison, including "long double"
for all temporary/local variables, you are really getting significantly
more accurate results, they just won't be identical to a run-of-the-mill
cpu with simple double precision hw.
If the remaining difference is critical, try SSE2 on Pentium4: This is
an exact double precision engine, with the added benefit that you can
work with pairs of doubles in parallel if you want to.
"almost all programming can be viewed as an exercise in caching"