------- Comment #62 from whaley at cs dot utsa dot edu 2006-08-10 15:15 ------- Paolo,
>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? :) Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
