https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #2) > I bet the above mentioned commit just tweaked things so that we now compare > in a hash table something we didn't compare before. > equal_mem_array_ref_p is called with: > t0 > MEM[(struct BorderValue *)&D.1753192 + 16B].m_isAuto > with > <integer_type 0x7fffe32ccb28 sizes-gimplified public unsigned QI > size <integer_cst 0x7fffea7f5f60 type <integer_type 0x7fffea8130a8 > bitsizetype> constant 8> > unit-size <integer_cst 0x7fffea7f5f78 type <integer_type 0x7fffea813000 > sizetype> constant 1> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7fffe32ccb28 precision:1 min <integer_cst 0x7fffe3e01468 0> max > <integer_cst 0x7fffe3e014b0 1>> > type, and > t1 > MEM[(bool *)this_59(D) + 722B] > with a const bool type. > As both types are unsigned integral types with precision 1, they are > considered compatible. > But because one is a COMPONENT_REF and m_isAuto is 1-bit bitfield, we get > sz0 and max0 1-bit (for COMPONENT_REFs we use DECL_SIZE of the FIELD_DECL, > so 1-bit), while the other is a MEM_REF with bool type and we use mode size > of the QImode. > types_compatible_p guarantees that the mode is the same and precision is the > same, but it doesn't apply we use the mode or precision in both cases. > > So, the > /* Types were compatible, so this is a sanity check. */ > gcc_assert (known_eq (sz0, sz1)); > looks bogus to me, either we should just punt if the sizes aren't equal, or > we should ignore the sizes (just remove the assert). Since we hash the size the correct thing to do is return false for maybe_ne (sz0, sz1) > I believe this bug is latent since r232559, before that change it used to > handle just MEM_REF and ARRAY_REF and for those get_ref_base_and_extent uses > always the TYPE_SIZE for BLKmode types or mode size otherwise, so for > types_compatible_p necessarily the same thing.
