[Bug rtl-optimization/50782] New: optimize pragma not applying fast-math

[ejtttje at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50782

             Bug #: 50782
           Summary: optimize pragma not applying fast-math
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: ejtt...@gmail.com


Summary: The optimize attribute works, but the pragma doesn't (for fast-math).

Test case:

#include <iostream>
#include <cmath>
#include <limits>

float n = std::numeric_limits<float>::quiet_NaN();

void test1() __attribute__((optimize("fast-math")));
void test1() {
    std::cout << std::isnan(n)<<__builtin_isnan(n)<<(n!=n) << std::endl;
}

#pragma GCC optimize ("fast-math")
void test2();
void test2() {
    std::cout << std::isnan(n)<<__builtin_isnan(n)<<(n!=n) << std::endl;
}

int main(int argc, char** argv) {
    test1(); test2(); return 0;
}

Output of 4.6.1-9ubuntu3 with -O3:
100
111

Expected output:
100
100

The two lines should be identical, yes?  It seems the attribute is applied to
test1, but the pragma isn't catching test2.  Apologies if I'm not using the
pragma correctly.

Also, I'm not really sure what to expect for the first two values of each line,
it depends on whether the inlining is done before or after optimization.  It
appears the built-in is expanded before optimization, but the isnan() is after
(I checked with nm, isnan is indeed inlined due to -O).  So up to you if that
is an issue.  Ironically, this is exactly the behavior I was looking for in bug
50724, but I wouldn't want to rely on this since you could decide to make this
attribute apply after inlining... however, if there is a definite behavior
regarding inlined function calls, you might want to document that?

Finally, this may be a tangent, but the implied finite-math-only is not setting
__FINITE_MATH_ONLY__==1.  That seems reasonable for the attribute, because
AFAIK this attribute processing runs after the preprocessor is done, right? 
But maybe the pragma could be setting it?  This might warrant a note in the
'optimize' attribute/pragma docs regarding the (in)ability of each to update
preprocessor flags.

Thanks!