This is the mail archive of the 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: RFC: Add ADD_RESTRICT tree code


On Wed, 12 Oct 2011, Jakub Jelinek wrote:

> > Assignment 2 means that t->p points to s.p.  Assignment 3 changes t->p and 
> > s.p, but the change to s.p doesn't occur through a pointer based on t->p 
> > or any other restrict pointer, in fact it doesn't occur through any 
> > explicit initialization or assignment, but rather through in indirect 
> > access via a different pointer.  Hence the accesses to the same memory 
> > object at s.p[0] and t->p[0] were undefined because both accesses weren't 
> > through pointers based on each other.
> Only the field p in the structure is restrict qualified, there is no
> restrict qualification on the other pointers (e.g. t is not restrict).
> Thus, it is valid that t points to s.  And, s.p[0] access is based on s.p
> as well as t->p and similarly t->p[0] access is based on s.p as well as
> t->p, in the sense of the ISO C99 restrict wording.

IMO reading the standard to allow an access to be 
based "on s.p _as well as_ t->p" and that this should result in any 
sensible behaviour regarding restrict is interpreting too much into it.  
Let's do away with the fields, trying to capture the core of the 
disagreement.  What you seem to be saying is that this code is 
well-defined and shouldn't return 1:

int foo (int * _a, int * _b)
  int * restrict a = _a;
  int * restrict b = _b;
  int * restrict *pa = wrap (&a);                                       
  *pa = _b;         // 1
  *a = 0;
  **pa = 1;
  return *a;

I think that would go straight against the intent of restrict.  I'd read 
the standard as making the above trick undefined.

> Because, if you change t->p (or s.p) at some point in between t->p = q; 
> and s.p[0]; (i.e. prior to the access) to point to a copy of the array, 
> both s.p and t->p change.

Yes, but the question is, if the very modification of t->p was valid to 
start with.  In my example above insn 1 is a funny way to write "a = _b", 
i.e. reassigning the already set restrict pointer a to the one that also 
is already in b.  Simplifying the above then leads to:

int foo (int * _a, int * _b)
  int * restrict a = _a;
  int * restrict b = _b;
  a = _b;
  *a = 0;
  *b = 1;
  return *a;

which I think is undefined because of the fourth clause (multiple 
modifying accesses to the same underlying object X need to go through one 
particular restrict chain).

Seen from another perspective your reading would introduce an 
inconsistency with composition.  Let's assume we have this function 

int tail (int * restrict a, int * restrict b) {
  *a = 0;
  *b = 1;
  return *a;

Clearly we can optimize this into { *a=0;*b=1;return 0; } without 
looking at the context.  Now write the testcase or my example above in 
terms of that function:

int goo (int *p, int *q)
  struct S s, *t;
  s.a = 1;
  s.p = p;       // 1
  t = wrap(&s);  // 2 t=&s in effect, but GCC doesn't see this
  t->p = q;      // 3
  return tail (s.p, t->p);

Now we get the same behaviour of returning a zero.  Something must be 
undefined here, and it's not in tail itself.  It's either the call of 
tail, the implicit modification of s.p with writes to t->p or the 
existence of two separate restrict pointers of the same value.  I think 
the production of two separate equal-value restrict pointers via 
indirect modification is the undefinedness, and _if_ the standard can be 
read in a way that this is supposed to be valid then it needs to be 
clarified to not allow that anymore.

I believe the standard should say something to the effect of disallowing 
modifying restrict pointers after they are initialized/assigned to once.


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