https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
This goes wrong in update_address_taken before into-SSA which removes
TREE_ADDRESSABLE from 'v' without transforming it in any way.
<bb 2> :
D.3193 = VIEW_CONVERT_EXPR<int[4]>(v)[18446744073709551615];
return D.3193;
update_address_taken uses maybe_rewrite_mem_ref_base to rewrite rvalues
but that leaves all outer handled components in place - in fact it
even puts a VIEW_CONVERT_EXPR around it.
For a "valid" testcase
typedef int v4si __attribute__((vector_size(16)));
int foo (v4si v)
{
return v[1];
}
the frontend produces
return VIEW_CONVERT_EXPR<int[4]>(v)[1];
and we then gimplify it to
D.2755 = BIT_FIELD_REF <v, 32, 32>;
via folding the stmt and maybe_canonicalize_mem_ref_addr, but we refrain from
doing that for out-of-bound accesses.
We do not have good IL verification for the differences between valid GIMPLE
and valid GIMPLE SSA - verify_gimple_* verifies GIMPLE and verify_ssa
doesn't apply any additional IL constraints.
I think we do not want ARRAY_REF of SSA_NAMEs nor do we want multi-level
handled_components on SSA_NAMEs.
Either we have to be way more aggressive in rewriting the refs
(use get_ref_base_and_extent?) to BIT_FIELD_REFs or in this case to
in-bound refs or zero or we have to restrict the rewrite to the cases
we already handle (which is very few special cases around MEM_REF[&decl]).
I'm trying to see what doing the latter regresses.
