GCC beaten by ICC in stupid trig test!

[Richard Guenther]

Robert Dewar wrote:
> Joe Buck wrote:
> 
>> On Tue, Mar 23, 2004 at 10:32:13PM -0500, Robert Dewar wrote:
>>
>>> Well I don't know exactly what stuff is in -ffast-math, but I suspect 
>>> it is a mistake to just think in terms of rounding error vs the 
>>> mantissa length. 
>>
>>  
>> Most of the optimizations have to do with ignoring the need to 
>> distinguish
>> +0 and -0, or handle NaNs.
>>
>>> For example, if -ffast-math is so sloppy as to consider
>>> that (a+b)+c can be replaced by a+(b+c), then all bets are off.
>>
>>
>> That's why -ffast-math doesn't do that; such a transformation would be
>> massively brain-damaged.
> 
> 
> It would be a useful achievement in this thread if everyone understood
> the truth of the above sentence. Clearly that is not the case from other
> contributions to the thread :-)

Well, first this (transforming (a+b)+c to a+(b+c)) would be a question 
of if the language standard permits this.  After this, I personally 
would like to have a way to override associativity, and I cannot see
a clearer way as to write (a+b)+c instead of a+b+c.  But that may be a 
language standard question again.  If (a+b)+c doesn't do it, I cannot 
see another way of really forcing evaluation order.

Another question would be, if a+b+c is always (a+b)+c, or if it is 
(a+(b+c)) or if this is (should be) unspecified.  Maybe we'd need
-fpreserve-left-to-right-evaluation-order?  This way 1.0+a+1.0 should 
not be transformed to 2.0+a or a+2.0.

Richard.