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 restrict qualification work). See
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01011.html. "
The RFC patch was introduced with the words:
On October 12, 2011, Michael Matz wrote:
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 the aliasing machinery to associate it with a restrict tag uid.
In particular it will be possible to associate pointers coming from
different inline instance of the same function with the same restrict tag,
and hence make them conflict.
I think such a patch is useful for C/C++, but it seems to be also the
best way to fix the tree-checking issues one runs into with Fortran
code, where a derived-type ("struct") declaration contains fields which
are allocatables ("restricted" pointers) but they loose their restricted
property if the type is used to declare a variable with TARGET
attribute. (For the issue in full glory, read the 93 comments in PR
fortran/45586.)
Tobias
