https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
