Handle data dependence relations with different bases

Richard Biener richard.guenther@gmail.com
Tue May 9 10:21:00 GMT 2017


On Fri, May 5, 2017 at 11:27 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On 4 May 2017 14:12:04 CEST, Richard Biener <richard.guenther@gmail.com> wrote:
>
>>nonoverlapping_component_refs_of_decl_p
>>should simply skip ARRAY_REFs - but I also see there:
>>
>>    /* ??? We cannot simply use the type of operand #0 of the refs here
>>      as the Fortran compiler smuggles type punning into COMPONENT_REFs
>>      for common blocks instead of using unions like everyone else.  */
>>      tree type1 = DECL_CONTEXT (field1);
>>      tree type2 = DECL_CONTEXT (field2);
>>
>>so you probably can't simply use TREE_TYPE (outer_ref) for type
>>compatibility.
>>You also may not use types_compatible_p here as for LTO that is _way_
>>too
>>lax for aggregates.  The above uses
>>
>>    /* We cannot disambiguate fields in a union or qualified union.  */
>>      if (type1 != type2 || TREE_CODE (type1) != RECORD_TYPE)
>>         return false;
>>
>>so you should also bail out on unions here, rather than the check you
>>do later.
>>
>>You seem to rely on getting an access_fn entry for each
>>handled_component_p.
>>It looks like this is the case -- we even seem to stop at unions (with
>>the same
>>fortran "issue").  I'm not sure that's the best thing to do but you
>>rely on that.
>
> Is there a PR for the (IIUC) common as union?
> Maybe around
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
> COMMON block, BIND(C) and LTO interoperability issues

I'm not sure, this is Erics code so maybe he remembers.

Richard.

> Thanks



More information about the Gcc-patches mailing list