[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 11 May 2023, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
> 
> --- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> 
> > but the issue with the PHI node remains unless we sink the &str part
> > (but there's many uses of __i_14).  I guess it's still the "easiest"
> > way to get rangers help.  Aka make
> > 
> >  # __i_14' = PHI <1(10), 2(9)>
> >  __i_14 = &str + __i_14'; // would be a POINTER_PLUS_EXPR
> > 
> > it's probably still not a complete fix but maybe a good start.  Of course
> > it increases the number of stmts - &MEM[&str + 1B] was an 'invariant'
> > (of course the PHI result isn't).  There's not a good place for this
> > transform - we never "fold" PHIs (and this would be an un-folding).
> 
> Ughh, that sucks.  Let's see if Andrew has any ideas, but on my end I won't be
> able to work on prange until much later this cycle-- assuming I finish what I
> have on my plate.

So the idea with the above is of course that via regular folding
and value-numbering we can simplify the compare to a compare of
just the offsets and for those ranger already works.  The expression
is quite obfuscated of course and as said the strlen pass placement
doesn't help (it's before forwprop and VRP).

That said, the place to transform the PHI node is probably the same
where degenerate PHIs are removed.

For the testcase the PHI is created quite early by cunrolli.

I have a patch splitting the PHI.  We then still have

  # _69 = PHI <1(9), 2(8)>
  __i_44 = &str + _69;
...
  <bb 14> [local count: 402445658]:
  _51 = (unsigned long) &MEM <char[3]> [(void *)&str + 2B];
  _4 = (unsigned long) __i_44;
  _12 = -_4;
  _119 = _51 + 18446744073709551615;
  _48 = _119 - _4;
  _46 = _48 > 13;
  if (_46 != 0)
    goto <bb 15>; [64.00%]

and also

  _31 = &MEM <char[3]> [(void *)&str + 3B] <= __i_44;

so at least for the latter we are missing a simplification
pattern - it should simplify the compare to

  _31 = 3 <= _69

possibly (unsigned)(p p+ offset) should be changed to
(unsigned)p + offset and thus likewise (unsigned) &MEM[&str + 4B] into
(unsigned)&str + 4.