[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
whaley at cs dot utsa dot edu
Thu Aug 10 15:16:00 GMT 2006
------- Comment #62 from whaley at cs dot utsa dot edu 2006-08-10 15:15 -------
>The IEEE standard mandates particular rules for performing operations on
>infinities, NaNs, signed zeros, denormals, ... The C standard, by
>mandating no reassociation, ensures that you don't mess with NaNs,
>infinities, and signed zeros. As soon as you perform reassociation,
>there is *no way* you can be sure that you get IEEE-compliant math.
No, again this is a conflation of the issues. You have IEEE-compliant math,
but the differing orderings provide different summations of those values. It
is a ANSI/ISO C rule being violated, not an IEEE. Each individual operation is
IEEE, and therefore both results are IEEE-compliant, but since the C rule
requiring order has been broken, some codes will break. However, they break
not because of a violation of IEEE, but because of a violation of ANSI/ISO C.
I can certify whether my code can take this violation of ANSI/ISO C by
examining my code. I cannot certify my code works w/o IEEE by examining it,
since that means a+b is now essentially undefined.
>http://citeseer.ist.psu.edu/589698.html is an example of a paper that
>shows FP code that avoids accuracy problems. Any kind of reassociation
>will break that code, and lower its accuracy. That's why reassociation
>is an "unsafe" math optimization.
Please note I never argued it is was safe. Violating the C usage rules is
always unsafe. However, as explained above, I can certify my code for
reordering by examination, but nothing helps an IEEE violation. My problem is
lumping in IEEE violations (such as 3dNow vectorization, or turning on non-IEEE
mode in SSE) with C violations.
>If you want a -freassociate-fp math, open an enhancement PR and somebody
Ah, you mean like I asked about in end of 2nd paragraph of Comment #56?
>might be more than happy to separate reassociation from the other
>effects of -funsafe-math-optimizations.
What I'm arguing for is not lumping in violations of ISO/ANSI C with IEEE
violations, but you are right that this would fix my particular case. From
what I see, -funsafe ought to be redefined as violating ANSI/ISO alone, and not
mention IEEE at all.
>(Independent of this, you should also open a separate PR for ATLAS
>vectorization, because that would not be a regression and would not be
>on x87) :-)
You mean like I pleaded for in the last paragraph of Comment #38, but
reluctantly shoved in here because that's what people seemed to want? :)
More information about the Gcc-bugs