[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516

--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
So the problems seems to be that get_ref_base_an_extent returns
different sizes for expressions of the same type - specifically a
RECORD_TYPE with padding -  when one is a standalone VAR_DECL and the
other a field within another VAR_DECL.

This leads to SRA tripping over with the following input, where struct
h contains nothing but field of type struct e.

  struct h D.2475;
  struct h l;
  struct c k;
  struct e D.2392;
  ...
  D.2475 = MEM[(const struct h &)&D.2392];
  l = D.2475;
  ...
  <bb 5> :
  b::i (_11, l.D.2346);

so the l.D.2346 reference is reported to have 96 bits its access is
propagated to D.2475 and then in turn to D.2392, always as a struct h
96 bit access.  But D.2392 itself also has type struct h, and so we
end up with one struct h access within another, the former having 128
bits and the latter only 96, and both having the same expr - an expr
which get_ref_base_an_extent in the verifier thinks should be bigger.

Since no scalar types are involved, all of this has no impact on
codegen.  Therefore I am tempted to simply relax the assert to only
check max_size for register types.  Perhaps we should also check that
we never create access of the same or compatible type as the parent
access when propagating across assignments because that is the only
case in which we end up with this confusing expr.  Or perhaps both.