This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: Reorganize -ffast-math code.


In article <200103080023.TAA32688@zakon.math.purdue.edu> you write:
>
>But this is irrelevant to what I said; my point stands.  The current
>GCC will, behind the user's back, stuff an object into a slot with
>less precision and less dynamic range.

Your entire argument hinges on this, and it's NOT TRUE.

What is true is that gcc may end up using an intermediate representation
that has _more_ precision and _more_ dynamic range than the user asked
for.  The user asked for a "double" which is normally a 64-bit IEEE
double, yet most of the math ends up being done in 80-bit arithmetic. 
Or the user might ask for a 32-bit float, and the arithmetic might be
done in either doubles or the 80-bit extended form. 

Is it IEEE-conforming? No.  The x86 makes true IEEE uncomfortably hard
to achieve. 

Do some people expect IEEE? Yes.  But not many care about the exact
rounding, and most people who _really_ depend on IEEE rounding etc had
better know a lot about the problems they are working with, and
hopefully can be aware of things like the strange x86 rules. 

Your point? It doesn't seem to stand up at all. 

Floating point is dangerous.  It's not infinite-precision exact math. 
People don't always know that, or even when they know, they sometimes
forget.  So people are sometimes surprised by a result that they _think_
should be exactly 10 being calculated as 9.99999999999 and ending up
rounded to 9. 

But your point that gcc silently truncates values is bogus.  It
sometimes silently uses _more_ precision, and that can be problematic. 
But as people have tried to explain on this list, it's really hard to
avoid on x86 (people have pointed out errors in the original suggestion
of defaulting to a 53-bit mantissa rounding - it still doesn't give IEEE
even for "double" due to exponent size issues, much less than for
"float").

If you know what you're doing, you should set the rounding mode by hand. 
It's nasty, yes.  The compiler cannot do a very good job of it
automatically on x86, at least not until everybody uses the new FP
extensions that don't exist on most PCs at this writing.. 

		Linus


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