This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Thu, 24 Dec 2015 11:15:52 +0100
- Subject: Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4bkJNSaaqoxxC5ttCf8pZrvkts6jYKNPXiPAqqR2mHM0w at mail dot gmail dot com> <A27D18E9-EC3D-4F36-A3AE-F574C6324618 at gmail dot com> <CAFULd4ZrRQ+N63ADe+=oEvzE9q2uBd9yaJg8XSMBFcVuTJ39+Q at mail dot gmail dot com> <E1834E20-5836-4059-89C1-1FEB5885F8A5 at gmail dot com>
> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak <ubizjak@gmail.com> wrote:
> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
> ><richard.guenther@gmail.com> wrote:
> >> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak
> ><ubizjak@gmail.com> wrote:
> >>>Hello!
> >>>
> >>>There is a logic error in Honza's patch "Transparent alias suport
> >part
> >>>10" [1]. The part in memrefs_conflict_p should be changed to:
> >>>
> >>>- /* If decls are different or we know by offsets that there is
> >no
> >>>overlap,
> >>>- we win. */
> >>>- if (!cmp || !offset_overlap_p (c, xsize, ysize))
> >>>+ /* If decls are different and we know by offsets that
> >>>+ there is no overlap, we win. */
> >>>+ if (!cmp && !offset_overlap_p (c, xsize, ysize))
> >>> return 0;
> >>>- /* Decls may or may not be different and offsets overlap....*/
> >>>+ /* Decls are different and offsets overlap....*/
> >>>
> >>>Even if decls are different, their offsets shouldn't overlap!
> >>
> >> Comparing offsets of different decls does not make sense.
> >
> >Uh, yes, some more eyeballing was needed, but you are right.
> >
> >Is there a way to detect aliasing in case AND addresses are involved?
> >
> >Probably we need something like in base_alias_check, where:
>
> Yeah, and in that case just give up.
Yep, I will look into it ASAP.
comparing offsets of different decls is intended tohandle the case
where one decl is foo and other bar. We do not know of foo is not alias
of bar, but if offsets are different, we can still disambiguate
This needs to be tought over WRT anchors anyway.
Honza
>
> Richard.
>
> >--cut here--
> >/* The base addresses are different expressions. If they are not
> >accessed
> > via AND, there is no conflict. We can bring knowledge of object
> > alignment into play here. For example, on alpha, "char a, b;" can
> > alias one another, though "char a; long b;" cannot. AND addesses may
> > implicitly alias surrounding objects; i.e. unaligned access in DImode
> > via AND address can alias all surrounding object types except those
> > with aligment 8 or higher. */
> > if (GET_CODE (x) == AND && GET_CODE (y) == AND)
> > return 1;
> > if (GET_CODE (x) == AND
> > && (!CONST_INT_P (XEXP (x, 1))
> > || (int) GET_MODE_UNIT_SIZE (y_mode) < -INTVAL (XEXP (x, 1))))
> > return 1;
> > if (GET_CODE (y) == AND
> > && (!CONST_INT_P (XEXP (y, 1))
> > || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1))))
> > return 1;
> >--cut here-
> >
> >Uros.
>