[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Wasn't this discussed in the past in other PRs?  Whether uninitialized vars
> > mean anything or anything but same value each time a SSA_NAME initialized to
> > it is used?
> 
> I think you are talking about PR 100810 and the discussions around the patch
> that fixed that.

Yep, it looks exactly like such a case - IVOPTs is replacing 'h' in the
second inner loop with an expression based on 'i' and places the computation
of 'h' before the early exit (because that's where the original 'h' IV PHI
is defined).  I think the placement doesn't make a difference but replacing
the loop exit test does?

Anyway, GCC doesn't ensure stability of uninitialized values which means
any expressions derived become indeterminate, i_1(D) - i_1(D) isn't
guaranteed to be zero if you obfuscate that a bit.  That puts the burden
on compiler passes to never introduce new intermediate values since
whether any of the expression participating values are not initialized
might only become visible later.  OK, maybe that's too restrictive, but
I certainly warned that the fix in PR100810 is going to be whack-a-mole
playing.

Here we have

marking _19 as maybe-undef
marking _44 as maybe-undef because of _19

but then we have

  <bb 3> [local count: 118111601]:
  # a.6_39 = PHI <_8(13), a.6_32(11)>
  # h_41 = PHI <h_21(13), 0(11)>
  # i_44 = PHI <i_43(13), i_19(D)(11)>
  g = 0; 
  _1 = i_44 % 2;
  f.1_2 = f; 
  if (a.6_39 < h_41)

note how the use of i was hoisted which makes the

          /* Look for any uses of the maybe-unused SSA_NAME that
             dominates the block that reaches the incoming block
             corresponding to the PHI arg in which it is mentioned.
             That means we can assume the SSA_NAME is defined in that
             path, so we only mark a PHI result as maybe-undef if we
             find an unused reaching SSA_NAME.  */
          int idx = phi_arg_index_from_use (use_p);
          basic_block bb = gimple_phi_arg_edge (phi, idx)->src;
          if (ssa_name_any_use_dominates_bb_p (var, bb))
            continue;

logic fail.  It's invariant motion that moves this use (I think we have
a duplicate issue with regarding to -Wuninitialized for this kind of
transform):

_1 = i_44 % 2;
  invariant up to level 2, cost 20.
...
Moving statement
_1 = i_44 % 2;
(cost 20) out of loop 2.

We could try to use the same mark_ssa_maybe_undefs in invariant motion
but it might not be a trivial exercise.  I also question sustainability
of how we extend exploitation of undefinedness in GCC ... :/