https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
--- Comment #20 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to rguent...@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?
