This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha


> 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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]