This is the mail archive of the gcc-bugs@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]

[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > int
> > foo (int *__restrict__ ap)
> > {
> >   int *bp = ap;
> > #pragma omp parallel for
> >   for (unsigned int idx = 0; idx < N; idx++)
> >     ap[idx] = bp[idx];
> > }
> > 
> > I believe this testcase is invalid as you access *ap through bp which is
> > not based on ap.
> > 
> 
> Modifying ap to point to a copy of *ap will modify the value of bp (when
> done before the copy from ap to bp), so to me it looks like bp is based on
> ap.

I suppose your line of reasoning is what you wrote here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885#c15 ):
...
The standard has some interesting wording to define "based-on".  IIRC
it goes like a pointer is based on 'p' if the value of the pointer
changes when you modify 'p'.  I think that only allows for expressions
based on p, like (p + 1) or &p[2].  It does _not_ allow for new
temporaries, like q = p + 1; as if you modify p q doesn't change.
...
?

At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67705#c1 I find:
...
3 In what follows, a pointer expression E is said to be based on object P if
(at some sequence point in the execution of B prior to the evaluation of E)
modifying P to point to a copy of the array object into which it formerly
pointed would change the value of E).
...

Hmm, my reasoning was that in this example, modifying ap at sequence point 2, 
changes the value of bp at the point of evaluation of bp (*bp = 1). 
...
{
  /* sequence point 1.  */
  unsigned int *restrict ap = ...;
  /* sequence point 2.  */
  unsigned int *bp = ap;
  /* sequence point 3.  */
  *ap = 1;
  /* sequence point 4.  */
  *bp = 1;
  /* sequence point 5.  */
}
...

So AFAIU the difference in interpretation is related to whether the sequence
point mentioned in the standard relates to:
a. both the point of modifying P, and sampling the value of E to determine
   whether it changed, or just
b. just the point of modifying P, while the value of E is sampled at the
mentioned
   'evaluation of E'.

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