[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.