Thank you for your reply, Tim. Tim Prince <n8tm@xxxxxxx> writes: > On 2/15/2010 5:23 PM, Neil Ferguson wrote: >> Christoph Groth wrote: >> >> <snipped inconsistent floating point results> >> >>> This is on a computer with an Intel Core 2 CPU (I tried several >>> different variants). >>> >>> If I take the second (-O1) binary and execute it on an Opteron it >>> produces the _first_ result. Thus, the same static binary produces >>> different results on different processors! >> >> This is a hardware-related effect - in a nutshell, it happens because >> Intel hardware can extend double-precision floating point operations >> to 80 bits internally, whereas AMD hardware usually enforces 64 bits >> at all times. >> > OP didn't indicate that -mfpmath=387 was used for the Intel run, > vs. -mfpmath=sse for the AMD one. It has to be guessed that the > rounding mode was set differently, or (if a 387 build) precision mode > was set differently, or (if an sse build) gradual underflow was set > differently. Both of you are too quick to blame gcc or Intel or AMD > for something which almost certainly stems from other influences. It was an sse build (default on core2). How to set "gradual underflow" consistently? -frounding-math does not help. Should the same binary not produce the same output on a processor with the same instruction set, no matter what the compiling options were?
