This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 08 Apr 2016 14:37:55 +0000
- Subject: [Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes
- Auto-submitted: auto-generated
- References: <bug-70586-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70586
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 38224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38224&action=edit
gcc6-pr70586.patch
Untested fix. In my understanding, even const functions can contain floating
point math (that could raise floating point exceptions) or integer
division/modulo without constant divisor, at least our pure/const discovery
doesn't care about those, and I bet the vast majority of floating point const
functions could in some cases raise exceptions etc.
Thus IMHO for ifcombine no side effects discovery even const calls are
problematic, we shouldn't move calls to them before conditions that originally
guarded them, as in this example where the (after fnsplit) condition in the
caller checks that the second argument is not 0 and only calls the const
function if the second argument is non-zero, but ifcombine arranges for the
condition to be tested only after the call instead of before it.