https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69938
--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So we have these statements during SRA:
_4 = e[d.1_3];
_5 = (int) _4;
We delete the first statement, presumably because we're going to apply SRA to
the RHS of that statement. That releases _4 back to the manager, leaving this
IL:
;; basic block 2, loop depth 0
;; pred: ENTRY
b.0_11 = b;
_12 = (unsigned char) b.0_11;
MEM[(unsigned char *)&e + 16B] = _12;
_13 = a;
d.1_3 = d;
_5 = (int) _4;
d = _5;
MEM[(char * {ref-all})&c] = MEM[(char * {ref-all})&e];
e ={v} {CLOBBER};
return;
;; succ: EXIT
And we call sra_modify_assign on the _5 = (int) _4 statement.
But that statement does not satisfy gimple_assign_single_p so sra_modify_assign
does nothing. That leaves the dangling reference to _4 in the IL and we
ultimately blow up in the gimple verification routines.
I've never looked at tree-sra in detail before. But ISTM given the structure
of sra_modify_assign that we assume that if we delete a statement like we've
done here that all references are going to get fixed by subsequent calls to
sra_modify_assign. sra_modify_assign punts anything that is not
gimple_assign_single_p, so perhaps we're missing a similar test elsewhere in
tree-sra.c.
