This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add ADD_RESTRICT tree code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]