Re: [PATCH] PR58143/58227 wrong code at -O3

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger
<bernd.edlinger@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.edlinger@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