https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).
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.
