On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > The lim pass (aka loop invariant motion) can move conditional expressions > with possible undefined behavior out of the if statement inside a loop which > may cause the loop optimization to silently generate wrong code as PR > tree-optimization/58143 and PR tree-optimization/58227 demonstrate. > > This patch prevents lim from moving code that might cause undefined behavior. > > This triggered a minor regression in gcc.target/i386/pr53397-1.c: > Here lim used to move the expression "2*step" out of the loop, but this may > cause undefined behavior on case of overflow, I propose to resolve this by > adding -fno-strict-overflow. The test case looks pretty constructed anyway. > > The patch was boot-strapped and regression tested on i686-pc-linux-gnu and > X86_64-linux-gnu > > OK for trunk?
2013-08-28 Bernd Edlinger <bernd.edlin...@hotmail.de> PR tree-optimization/58143 PR tree-optimization/58227 Prevent lim from moving conditional expressions if that could trigger undefined behavior. * gimple.h (gimple_could_trap_p_2): New function. * gimple.c (gimple_could_trap_p_2): New function. (gimple_could_trap_p_1): Call gimple_could_trap_p_2. * tree-ssa-loop-im.c (movement_possibility): Likewise. Please fold the overall comment into the movement_possibility changelog. Can you instead of introducing gimple_could_trap_p_2 simply change the signature and name of gimple_could_trap_p_1 please? It is only called three times. A proper name could be gimple_could_trap_or_invoke_undefined_p. That you need to change the two testcases makes me nervous (also please use -fwrapv, not -fno-strict-overflow) - did you check what happens for them? Thanks, Richard. > Regards > Bernd Edlinger
