https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Priority|P3 |P2
Last reconfirmed| |2023-04-21
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The assert is just a bit overzealous.
(gdb) p debug_bb ($2)
<bb 47> [local count: 708959595]:
# prephitmp_152 = PHI <_276(45), pretmp_2(46)>
# prephitmp_205 = PHI <_85(45), pretmp_341(46)>
# prephitmp_556 = PHI <_86(45), pretmp_298(46)>
# prephitmp_353 = PHI <_275(45), pretmp_555(46)>
result_282 = (void *) prephitmp_152;
_283 = prephitmp_152 + 8;
MEM[(struct Zone *)_86].position_ = _283;
vectp.1975_450 = result_282;
MEM <vector(2) int> [(int *)vectp.1975_450] = { 0, 0 };
use_stmt is the last stmt so code is SSA_NAME. But it's also an odd SLP graph
as we have two graphs we vectorize separately where parts of one graph
are used in address computes of another (the addresses we don't model in SLP
so we "fail" to merge the SLP graphs).
Going to be interesting to see whether a reduced testcase reproduces that.
Anyway, the easiest "fix" is to simply remove the assert. The assert is
not technically necessary, it's just there trying to "prove" we understand
the situations this hack is necessary (I don't think we do ;)).
