floating point inconsistency

Neil Ferguson nferguso@eso.org
Wed Feb 17 13:51:00 GMT 2010

Tim Prince wrote:
> 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.

You're right.

I misread the OP as having recompiled on AMD, when he actually copied his 
Intel-compiled binary to the AMD machine.


More information about the Gcc-help mailing list