This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC beaten by ICC in stupid trig test!

On Wed, Mar 24, 2004 at 01:21:32PM -0500, Bradley Lucier wrote:
> Re:
> > On Tue, Mar 23, 2004 at 10:32:13PM -0500, Robert Dewar wrote:
> > > 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.
> Well, -ffast-math (or more specifically, -funsafe-math-optimizations) 
> is about to do this, at least in some cases on tree-ssa, see
> If you think that this transformation shouldn't be done, then I guess 
> now is the time to speak up.

It's OK for -ffast-math to make the kind of transformation that might
lose the last bit or two of an IEEE FP result.  However, disregarding 
parentheses will frequently throw away far more precision than that.

Consider a, b, and c as single precision floating point values, and
a=1, b=-1, c=1.2345e-8.  (a+b)+c will compute as 1.2345e-8.  a+(b+c)
will return zero, as will (a+c)+b.  *All* the precision of the result,
every single bit, is lost.  This is because FLT_EPSILON is 1.1920929e-07F,
and 1.0F plus a value smaller than 1.0F gives zero.  Now, in on x86
you might not see this because the value is computed to 80 bits, but
what if you spill the partial sum?

And no, I'm not being pedantic; in many scientific apps, the programmer
is aware of the expected range of values the variables will have, and
will deliberately arrange the operations so that variables of similar
magnitudes are combined.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]