Given that GCC is again in Stage 1, I would like to bring attention to
the following RFC patch.
To quote Richard in PR 45586:
"I believe the correct solution will involve implementing the proposal
for introducing explicit restrict tags and using that in the fortran
frontend (removing the restr
On Wed, Oct 12, 2011 at 7:16 PM, Michael Matz wrote:
> Hi,
>
> this adds a mean to retain restrict information without relying on
> restrict casts. In the patch it's emitted by the gimplifier when it sees
> a norestrict->restrict cast (which from then on is useless), at which
> point also the tag
On Thu, 13 Oct 2011, Michael Matz wrote:
> Yeah. But I continue to think that this reading is against the intent (or
> should be). All the examples in the standard and rationale never say
> anything about pointers to restricted objects and the problematic cases
> one can construct with them,
Hi,
On Thu, 13 Oct 2011, Jakub Jelinek wrote:
> On Thu, Oct 13, 2011 at 02:57:56PM +0200, Michael Matz wrote:
> > struct S {int * restrict p;};
> > void foo (struct S *s, struct S *t) {
> > s->p[0] = 0;
> > t->p[0] = 1; // undefined if s->p == t->p; the caller was responsible
> >
On Thu, Oct 13, 2011 at 02:57:56PM +0200, Michael Matz wrote:
> struct S {int * restrict p;};
> void foo (struct S *s, struct S *t) {
> s->p[0] = 0;
> t->p[0] = 1; // undefined if s->p == t->p; the caller was responsible
> // to not do that
This is undefined only if s->p == t
Hi,
On Thu, 13 Oct 2011, Jakub Jelinek wrote:
> I'd sum up my previous mail as noting that restricted pointers are objects,
> so restrict is not property of expressions. So e.g. I don't think
> we should add ADD_RESTRICT (or, at least, not an ADD_RESTRICT with different
> tag) on every assignmen
On Thu, Oct 13, 2011 at 11:21:58AM +0200, Richard Guenther wrote:
> I suggested that for a final patch we only add ADD_RESTRICT in the
> gimplifier for restrict qualified parameters, to make the inlining case
> work again. ADD_RESTRICTs for casts to restrict qualified pointers
> I would add at par
On Thu, Oct 13, 2011 at 10:41 AM, Jakub Jelinek wrote:
> On Thu, Oct 13, 2011 at 01:38:44AM +0200, Michael Matz wrote:
>> 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 interpretin
On Thu, Oct 13, 2011 at 01:38:44AM +0200, Michael Matz wrote:
> 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.
No. Because s.p and t->p designates
Hi,
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 initial
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
Hi,
this adds a mean to retain restrict information without relying on
restrict casts. In the patch it's emitted by the gimplifier when it sees
a norestrict->restrict cast (which from then on is useless), at which
point also the tag of that restrict pointer is generated. That's later
used by
12 matches
Mail list logo
