Re: [RFC PATCH] restrict_based_on_field attribute

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 4 Oct 2011, Jakub Jelinek wrote:

> If it causes miscompilations, then GCC is buggy and needs to be fixed.

That's not easy without effectively making the whole restrict support 
ineffective.

> > Keep in mind that the whole current restrict-tag support was designed to 
> > support fortrans specific needs where we can rely on the compiler 
> > generating code we most probably (!) won't miscompile later.  Further we 
> > interpret some of the part where ISO-C says nothing in our favor.  
> > Together this means that e.g. (intentionally _not_ ISO-C, but sort of 
> > middle-end speak):
> > 
> > foo (struct s)
> > { restrict int *p1 = s.p;
> >   restrict int *p2 = s.p;
> >   *p1 = 0; *p2 = 1; return *p1;
> > }
> 
> Not sure what you mean here.  restrict int doesn't make sense,

I said that it wasn't C.  Read all my examples as "int * restrict pX", ...

> int *restrict p1 would make sense, but then it would be invalid C.

... and invalidity in C doesn't necessarily enter the picture.  The above 
is middle-end instructions and we need to say what we wish to happen with 
the above code (which _is_ generated by valid fortran use for instance, 
and could conceivably be generated by other middle-end transformation, 
e.g. code duplication.

> Loads don't generate new tags.

See Richis (upcoming) answer, that's one of the various hacks^Wdesign 
decisions made to at least get something useful out of the restrict tag 
things for fortran without breaking too much.

> > You introduce even more freedom to this mud.  Effectively:
> > 
> > foo (struct s)
> > { restrict int *p1 = s.p;
> >   restrict int *p2 = s.q; // same restrict tag as s.p
> > }
> 
> Again, in your above syntax it is unclear what is TYPE_RESTRICT, if it is
> TYPE_RESTRICT (TREE_TYPE (p1)) or something else.  If the user writes the
> above in C and then accesses both through p1 and p2 the same object, it is
> invalid.

Hmm?  I thought the point of your patch was precisely to make accesses 
through _M_start and _M_final have the same restrict tag, so that users 
can access the same object through both pointers, but still enjoy 
disambiguation with e.g. _M_start from different objects.  Possibly I've 
misunderstood.


Ciao,
Michael.