[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #8 from Marc Glisse --- (In reply to Vadim Zeitlin from comment #5) > Perhaps you could consider this as a QoI issue, but it would be really great > if gcc could give a warning if the code tries to use fesetround() without > -frounding-math being on. First note that even with -frounding-math, there are several bugs related to rounding (maybe rint isn't considered pure, but operators like +-*/ are). Also, there are ways (inline asm that hides optimization opportunities) to use fesetround safely even with -fno-rounding-math (and it avoids the perf penalty in places where we don't care about the rounding). Still, I guess we could consider such a warning, if someone is willing to implement it...
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #7 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #6) > https://gcc.gnu.org/wiki/FloatingPointMath Yes, I've seen this, thanks. But do you think it's easily discoverable? I admit I had even seen this page (and knew about -frounding-math option) before running into this problem after an upgrade to gcc 6 and it still wasn't obvious to me that the problem was due to this. You might just think that I'm abnormally clueless, but it seems to me that most people wouldn't be able to realize the source of the problem immediately. So a warning from the compiler would be really helpful IMO.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #6 from Andrew Pinski --- https://gcc.gnu.org/wiki/FloatingPointMath
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #5 from Vadim Zeitlin --- Yes, I did find this documentation myself in the meanwhile and I agree that you're formally correct, just as gcc developers are formally correct in the long discussion at #34678 (which I really wouldn't want to reopen), but this is not very helpful in practice because this information is completely undiscoverable, i.e. you can only find it if you already know what you're looking for (or enjoy reading compiler optimization options documentation as a hobby, of course). Perhaps you could consider this as a QoI issue, but it would be really great if gcc could give a warning if the code tries to use fesetround() without -frounding-math being on.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #4 from Andrew Pinski --- (In reply to Vadim Zeitlin from comment #3) > (In reply to Andrew Pinski from comment #1) > > You want -frounding-math > > OK, thanks, this does indeed solve my immediate problem. However is it > really normal that the compiler behaviour silently (!) changes like this, in > backwards incompatible way between versions? I didn't remember seeing this > change mentioned in gcc 6 release notes and I just reread them again and > can't find it anywhere. I think changes silently breaking existing working > (and standard conforming) code should be at the very least prominently > documented (and, of course, ideally completely avoided IMO, but this ship > has probably already sailed). Yes and no. Since this behavior has been documented this way since 4.4.0: https://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html -frounding-math Disable transformations and optimizations that assume default floating point rounding behavior. This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations. ___This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode. This option disables constant folding of floating point expressions at compile-time (which may be affected by rounding mode) and arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes. Note I add ___. So basically what changed between 5 and 6 was constant folding of rint. Since that is covered in the documentation, the change itself does not need to be documented as happening.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #3 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #1) > You want -frounding-math OK, thanks, this does indeed solve my immediate problem. However is it really normal that the compiler behaviour silently (!) changes like this, in backwards incompatible way between versions? I didn't remember seeing this change mentioned in gcc 6 release notes and I just reread them again and can't find it anywhere. I think changes silently breaking existing working (and standard conforming) code should be at the very least prominently documented (and, of course, ideally completely avoided IMO, but this ship has probably already sailed).
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 Marc Glisse changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2017-08-20 Resolution|INVALID |--- Summary|Calls to rint() wrongly |[7/8 Regression] Calls to |optimized away starting in |rint() wrongly optimized |g++ 6 |away starting in g++ 6 Ever confirmed|0 |1 --- Comment #2 from Marc Glisse --- Indeed you want -frounding-math, and with gcc-6 that makes things work, but starting with gcc-7 it doesn't anymore. (gimple looks fine, the problem comes later)
