https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118817
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> <bb 6> [local count: 751619280]:
> *_154 ={v} {CLOBBER(bob)};
> _227 = &_154->D.5702._M_local_buf;
> MEM[(struct _Alloc_hider *)_154] ={v} {CLOBBER(bob)};
> MEM[(struct _Alloc_hider *)_154]._M_p = _227;
> __builtin_memcpy (_227, "Three", 5);
> _154->_M_string_length = 5;
> MEM[(char_type &)_154 + 21] = 0;
>
> is what we diagnose.
>
> And the reason is we do
>
> _181 = operator new (64);
> ...
> _164 = _181 + 32;
> ...
> _154 = _164 + 32;
> ...
> _175 = _181 + 64;
> ...
> if (_154 != _175)
> goto <bb 6>; [70.00%]
>
> and we fail to eliminate the compare. Ugh.
It's catched by forwprop later which is the pass making _154 to be
_181 + 64 and then combining and simplifying the compare. That's
not done before the strlen pass.
This is also a missed value-numbering opportunity.
void bar ()
{
char *p = __builtin_malloc (16);
char *q = p + 8;
char *r = q + 8;
char *s = p + 16;
if (s != r)
*s = 1;
}
with -fno-tree-forwprop isn't optimized in the first FRE pass. Later
all VRP passes fold all stmts, that does the trick as well, but the
next VRP after PRE which introduces the above IL is only after strlenopt
as well. Both DOM and FRE only fold stmts that had changes and PRE
doesn't fold inserted stmts, it possibly should.
+Found partial redundancy for expression {pointer_plus_expr,__cur_17,32} (0013)
+Inserted _154 = _164 + 32;
+ in predecessor 60 (0013)
