This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Handle data dependence relations with different bases
- From: Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>,Richard Sandiford <richard dot sandiford at linaro dot org>
- Date: Fri, 05 May 2017 23:27:42 +0200
- Subject: Re: Handle data dependence relations with different bases
- Authentication-results: sourceware.org; auth=none
- References: <87tw52s73r.fsf@linaro.org> <CAFiYyc0XFciO8BEitmMSuDQbVTc60FXiaCKtQxoiSQ_RjKM4dQ@mail.gmail.com>
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
Thanks