Re: GCC beaten by ICC in stupid trig test!

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

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.