floating point inconsistency

[Christoph Groth]

Thank you for your reply, Tim.

Tim Prince <n8tm@aol.com> 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?