https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Feng Xue from comment #2)
> (In reply to Richard Biener from comment #1)
> > Yes, it's not possible to implement the standards restrict qualification
> > constraints reliably for pointers not in the outermost scope of a function
> > and after the compiler was allowed to do CSE or other code transforms.
> >
> > For simplicity only function parameters (and select "global" cases)
> > are handled in the implementation which resides in points-to analysis.
> >
> > In principle 'restrict' should be handled in the C/C++ language frontends
> > instead.
>
> Maybe, I caught your point, w/o front-end scope information, we do not know
> the effective lifetime of "__restrict__" pointer merely from def/use chain
> in the gimple. An example:
>
> void foo (int *p)
> {
> int *a_escaped;
>
> {
> int * __restrict__ a = ...;
>
> /* no alias between "a" and "p" */
> *a = ...;
>
> /* Make "a" escaped from block scope */
> a_escaped = a + offset;
> }
>
> /* By source-level declaration syntax, "a_escaped" and "p" may be
> aliased. But in the gimple, we do not know usage of "a_escaped" does not
> belongs to lifetime constrainted by "__restrict__", and could lead to an
> incorrect conclusion that "a_escaped" and "p" are alias-free. */
>
> *a_escaped = ...;
>
> ...
> }
>
> But for the 2nd case, all pointers are defined in the outermost scope of
> function. How about an enhancement? Besides parameters, we could also mark
> all __restrict__ pointers declared in the outermost scope, and ignore others
> in any enclosed scopes, as you said, probably this could be done that at the
> front-end stage.
Outermost scope would work as long as there is no inlining or optimization
happening before since we happily elide scopes and "globalize" variables.
That is, it's quite difficult to prove handling user(!) variables in the
outermost scope is correct. You'd check that DECL_CONTEXT of a variable
is the same as DECL_INITIAL (cfun->decl), but I'm not sure this will
never "break". Depending on frontends there might or might not be an
additional "outer" scope from DECL_INITIAL IIRC.
Does handling variables in the outermost scope matter in practice?
