This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 28 Mar 2011 09:32:12 +0000
- Subject: [Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
- Auto-submitted: auto-generated
- References: <bug-48295-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.03.28 09:31:53
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-28 09:31:53 UTC ---
Code motion optimizations (or even CSE) have no idea about dynamic rounding
mode changes, -frounding-math does not change this (this switch is only
guarding expression simplifications that usually assume round-to-nearest
behavior).
The only mode for which I'd accept such band-aid patches is -O0.
Anyway, confirmed, but long-time known with no idea when or even how
this is going to be fixed.
Btw, your testcase would be kindof invalid as you are not using the
documented standard way of accessing fenv but using inline-asm (and
we don't have a special clobber that tells GCC you touched the FP
control word).
As for CSE, try
/* Round to upward. */
tem1 = a + b;
/* Round to nearest. */
tem2 = a + b;
diff = tem1 - tem2;
and see it optimized to zero at compile-time.
I suppose there is a duplicate bug somewhere about the general issue.