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

[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: unassigned@gcc.gnu.org
        ReportedBy: ejtttje@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!

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

[ejtttje at gmail dot com]

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

--- Comment #1 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-18 21:16:23 UTC ---
I'm sorry, apparently I messed something up in my testing.

The output of -O3 is actually:
000
111

The output of -O0 is:
100
111

So the optimize attribute is being applied after/including any inlined
functions.  Obviously, when the function is not inlined, it is not affected by
the attribute.

The primary bug of the two lines not being the same remains the same.

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

[ejtttje at gmail dot com]

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

--- Comment #2 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-18 21:28:42 UTC ---
Argh, sorry for the spastic updates, but I checked again and I definitely have
these lines in my console history:
$ g++ test.cc -o test -Wall -g -O3 && ./test
100
111

But now I'm getting the 000/111 output for the same build command... I don't
understand the inconsistency *shrug* see what you get O:-)

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

[ejtttje at gmail dot com]

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

--- Comment #3 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-18 23:55:47 UTC ---
I figured out what I did differently, I did some 'minor cleanup' and moved n
out of the function scope.  This actually changes the optimization results.

This is just for reference in case you are interested:

Looking at the assembly for the three tests below, I confirmed printf is being
passed a constant value in each of them.  My theory is that in test1 gcc does a
const-eval of the isnan outside of the test function scope, whereas in the
other two it inlined isnan first and then optimized the constants within the
scope of the attribute.  Anyway this is just an example that the relationship
between the optimize attribute and inlined functions may be hard to predict (at
least, for people who aren't gcc maintainers ;))

#include <cmath>
#include <limits>
#include <cstdio>

void test1() __attribute__((optimize("fast-math")));
void test1() {
    const float n = std::numeric_limits<float>::quiet_NaN();
    printf("%d\n",std::isnan(n));
}

void test2() __attribute__((optimize("fast-math")));
void test2() {
    static const float n = std::numeric_limits<float>::quiet_NaN();
    printf("%d\n",std::isnan(n));
}

const float n = std::numeric_limits<float>::quiet_NaN();
void test3() __attribute__((optimize("fast-math")));
void test3() {
    printf("%d\n",std::isnan(n));
}

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

Output:
ejt@vbox-ubuntu-11:~$ g++ test.cc -o test -Wall -g -O3 && ./test
1
0
0
ejt@vbox-ubuntu-11:~$ nm test | c++filt | grep -i isnan
ejt@vbox-ubuntu-11:~$ g++ test.cc -o test -Wall -g -O0 && ./test
1
1
1
ejt@vbox-ubuntu-11:~$ nm test | c++filt | grep -i isnan
000000000040073a W __gnu_cxx::__enable_if<std::__is_arithmetic<float>::__value,
int>::__type std::isnan<float>(float)

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-19 08:16:34 UTC ---
The interaction of the optimize attribute/pragma with inlining are
"interesting".
For some options we prohibit inlining (but only for the target attribute/pragma
I think), otherwise the callee inherits the settings of the caller - sometimes
partly.