https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
for i in /tmp/rh1422456-_*.s; do j=`basename $i .s`; echo ===$j===; g++ -o
/tmp/$j{,.s}; /tmp/$j; done
===rh1422456-_150===
===rh1422456-_155===
===rh1422456-_192===
===rh1422456-_212===
===rh1422456-_233===
===rh1422456-_262===
===rh1422456-_286===
rh1422456-_286: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)
===rh1422456-_299===
===rh1422456-_335===
===rh1422456-_375===
rh1422456-_375: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)
===rh1422456-_416===
===rh1422456-_424===
===rh1422456-_460===
===rh1422456-_568===
===rh1422456-_647===
===rh1422456-_9===
rh1422456-_9: /tmp/rh1422456.C:50: int main(int, char**): Assertion `r && itr
== end' failed.
Aborted (core dumped)
So it is just 3 SSA_NAMEs that result in abort this time (and no invalid free
most likely). _9 is actually this_9(D), let me try _286 now how it affects the
tree dumps. Of course it might be some RTL bug only triggered through the
changes.
