https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 14 May 2018, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 > > --- Comment #22 from Marc Glisse <glisse at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #21) > > Note that in the strict C semantic thing __restrict on > > this isn't valid as the following is valid C++: > > > > Foo() __restrict > > { > > Foo *x = this; > > x->a = 1; > > this->a = 2; > > ... > > } > > > > but for C restrict you'd have two pointers with same provenance here. > > > How is that different from the C > > void Foo_const(Foo*const restrict t) > { > Foo *x = t; > x->a = 1; > t->a = 2; > } > > , which seems valid to me? it accesses the object pointed-to by the restrict qualified pointer via an lvalue that is not based on it in my reading of C11 6.7.3.1/3 (though "some" sequence point sounds like that being x = t makes it valid based on). Otherwise for restrict to be usable by a compiler it would need to perform conservative pointer propagation. Like void Foo(Foo **x, Foo * restrict t) { *x = t; t->a = 1; (*x)->a = 2; } or with Foo *baz(Foo *); Foo *x = baz(t); t->a = 1; x->a = 2; if x and t point to the same object my reading of the standard says thats undefined (GCC of course treats it conservatively instead).
