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.