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: RFC: Add ADD_RESTRICT tree code


On Wed, Oct 12, 2011 at 07:16:56PM +0200, Michael Matz wrote:
> This patch will fix the currently XFAILed tree-ssa/restrict-4.c again, as 
> well as fix PR 50419.  It also still fixes the original testcase of 
> PR 49279.  But it will break the checked in testcase for this bug report.  
> I believe the checked in testcase is invalid as follows:
> 
> struct S { int a; int *__restrict p; };
> 
> int
> foo (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
>   s.p[0] = 0;    // 4
>   t->p[0] = 1;   // 5
>   return s.p[0]; // 6
> }

I'm fairly sure this is completely valid.

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

"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.
Note that ââbasedââ is defined only for expressions with pointer types."

Which means that for memory restricts (fields in particular) we need to
limit ourselves to the cases where the field is accessed through a
restricted pointer or doesn't have address taken.

	Jakub


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