This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]