https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.
So inserting the same equivalence into the table twice results in the same
entry being added twice but pointed to the same expression.
Normally this doesn't happen during normal value CSEing because a virtual reg
is assigned only once so you ever only get one SET statement with the given
DEST.
What changed with my patch is that the vectors of const_int also get
equivalences to constants inside a vector, i.e. you can extract an element from
the vector should you need it.
e.g. this instruction
(insn 18 17 24 2 (set (subreg:V1SI (reg:SI 97 [ _10 ]) 0)
(const_vector:V1SI [
(const_int 0 [0])
])) "cse.c":11:9 1363 {*movv1si_internal}
(expr_list:REG_UNUSED (reg:SI 97 [ _10 ])
(nil)))
ends up generating two equivalences. the first one is that
reg:SI 97 is 0.
The second one is that 0 can be extracted from the V1SI, so subreg (subreg:V1SI
(reg:SI 97) 0) 0 == 0.
This nested subreg gets folded away to just reg:SI 97 and we re-insert the same
equivalence and end up with:
(rr) p dump_class (class1)
Equivalence chain for (reg:SI 105 [ iD.2893 ]):
(reg:SI 105 [ iD.2893 ])
$3 = void
(rr) p dump_class (class2)
Equivalence chain for (const_int 0 [0]):
(const_int 0 [0])
(reg:SI 97 [ _10 ])
(reg:SI 97 [ _10 ])
$4 = void
merge_equiv_classes then crashes because after it merges the first (reg:SI 97 [
_10 ]) the reference to it in class2 is invalid.
So I believe the fix should be that the hash table insertion code should not
insert a value if it already exists
in the table.
Testing a patch.
