https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125553
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- Value numbering stmt = g25.1_2 = g25; Setting value number of g25.1_2 to g25.1_2 (changed) ... Value numbering stmt = _6 = MEM[(v8i64 *)g24.0_1]; Setting value number of _6 to g25.1_2 (changed) Replaced MEM[(v8i64 *)g24.0_1] with g25.1_2 in all uses of _6 = MEM[(v8i64 *)g24.0_1]; ... Value numbering stmt = _7 = BIT_FIELD_REF <_6, 64, 0>; Skipping possible redundant definition g17 = 0; Inserting name _3 for expression BIT_FIELD_REF <g25.1_2, 64, 0> Setting value number of _7 to _7 (changed) so the issue is that vn_reference_lookup_3 builds the BIT_FIELD_REF and inserts it into the hash table but then fails doing vn_walk_cb_data::finish because 'same_val' is zero and it doesn't match _3. We then go and mark _7 VARYING, but the BIT_FIELD_REF we then insert has been recorded already. The issue is that with r16-3066-g53f491ccd1e59f we're looking up a reference that doesn't exist.
