https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #10)
> The array assignment from the front-end is good enough for the
> middle-end as far as IL type hygiene is concerned given the
> element types are useless-type-convertible.
Note, this has actually nothing to do with the frontend.
It initializes the types array correctly, I see INIT_EXPR with the types array
as first operand and CONSTRUCTOR with E[3] type which has values 0, 1, 2 (all
with E type).
But, on aarch64 (unlike x86_64 in this case) the gimplifier decides to use
tree_output_constant_def and initialize the array from loading that (rather
than e.g. initializing it elementwise). And that (through compare_constant)
intentionally ignores some type differences:
if (typecode == ARRAY_TYPE)
{
HOST_WIDE_INT size_1 = int_size_in_bytes (TREE_TYPE (t1));
/* For arrays, check that mode, size and storage order match. */
if (TYPE_MODE (TREE_TYPE (t1)) != TYPE_MODE (TREE_TYPE (t2))
|| size_1 == -1
|| size_1 != int_size_in_bytes (TREE_TYPE (t2))
|| TYPE_REVERSE_STORAGE_ORDER (TREE_TYPE (t1))
!= TYPE_REVERSE_STORAGE_ORDER (TREE_TYPE (t2)))
return false;
}
else
{
/* For record and union constructors, require exact type
equality. */
if (TREE_TYPE (t1) != TREE_TYPE (t2))
return false;
}
And given that there is a similar initializer with the exact same values
earlier but int type (the arr initializer, also { 0, 1, 2 }),
tree_output_constant_def just reuses that .LC0 var instead of creating a new
one.
So, I think this is solely a SRA bug.
Martin, could you please have a look?
