[Bug fortran/44882] Bogus types in references with mismatched commons

[egallager at gcc dot gnu.org]

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

--- Comment #20 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #19)
> On Thu, 5 Oct 2017, dominiq at lps dot ens.fr wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
> > 
> > --- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > The code in comment 1 is invalid, thus the FE can do what it likes. Would it be
> > enough to close this PR by emitting an error unless the code is compiled with
> > -std=legacy (as done for pr25071)?
> 
> Well, with -std=legacy the FE still emits "wrong code".  See comment#4
> where we have a VAR_DECL of type 0x7ffff5ad9888 but accessing it as
> if it were type 0x7ffff7fcb930 (the COMPONENT_REF arg 0 has a different
> , incompatible type than its arg 1 DECL_CONTEXT).  We've had tree
> verification for this in place at some point but IIRC I removed it
> because FEs didn't follow the rules.
> 
> A workaround for the FE would be, when it builds the COMPONENT_REF
> to access the 'dr' field, do
> 
>   if (TYPE_MAIN_VARIANT (TREE_TYPE (decl)) != TYPE_MAIN_VARIANT 
> (record_type))
>     decl = build1 (VIEW_CONVERT_EXPR, record_type, decl);
> 
> thus wrap the variable (in this case the common, and this is probably
> only ever needed for (blank) commons with -std=legacy) inside
> a VIEW_CONVERT_EXPR telling the middle-end we're trying to access
> the data with a type that is not the same as the declared type.
> 
> That'll also fix TBAA.

...so does this bug still need to be marked as WAITING then?