https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 23 Sep 2015, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885 > > --- Comment #12 from vries at gcc dot gnu.org --- > (In reply to Richard Biener from comment #11) > > I'm testing the above simple fix and amend the comment. > > Consider the example with functions f and g I gave in comment 10. Using the > patch from comment 11, I get at ealias: > ... > void f(int* __restrict__&, int*) (intD.9 * restrict & restrict pD.2252, intD.9 > * p2D.2253) > { > intD.9 * _3; > > # VUSE <.MEM_1(D)> > # PT = { D.2265 } (nonlocal) > _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1]; > > # .MEM_4 = VDEF <.MEM_1(D)> > MEM[(intD.9 *)_3 clique 1 base 2] = 1; > > # .MEM_6 = VDEF <.MEM_4> > MEM[(intD.9 *)p2_5(D) clique 1 base 0] = 2; > ... > > AFAIU, this is incorrect. The two stores can be now disambiguated based on > same > clique/different base, but in fact the stores can alias (in fact they do, in > the "f (gp, gp)" call from g). How is this a valid testcase? You are accessing g()s *gp through p and p2 even though p is marked as restrict. Did you mean to write void f (int *&__restrict__ p, int *p2) ?
