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: [PATCH, gfortran] Re: Cray Pointers


> >But you still can't use both to access the same object, right? ie. the
> >optimizers can assume that the two pointees don't alias.
> >
> >It would seem rather strange if two pointees can alias but a pointee and a
> >real object can't.
>
> There's no prohibition on pointees aliasing real objects or other
> pointees.  Both are common, in fact.  The trouble occurs when a
> pointee and an object that it aliases are both used in the same part
> of the program.  The optimizer isn't aware of the aliasing and things
> might break.  It's a sid effect a user must be aware of when using
> Cray pointers.  Here's an example of some legal (but fragile) code
> using Cray pointers, and the results of running that code:

That's not what your proposed update in the manual says.
There's no such thing as "legal but fragile code."
Code is either legal and works all the time, or it's not.

Just because a compiler accepts some code doesn't mean it is legal. In fact 
the majority of the requirements in the Fortran standard are requirements on 
the user writing the code. The compile need not, and in many cases can not 
issue and error when there rules are broken.

The code you gave is certainly not legal. You are modifying the actual 
argument associated with a dummy argument. This is prohibited by section 
12.4.1.6 of the fortran standard. The fact that every single compiler you 
tried broke the code also a good indication that the code is not ok.

Before I approve this patch I want know exactly what the aliasing rules for 
pointees are. I don't really care what the compiler accepts, just what is 
guaranteed to work and should be considered a bug in the compiler if it does 
not.  "Try it and see if it works" is not an acceptable way of specifying a 
new feature.

If there is common that breaks aliasing rules (eg. the code you posted), we 
need to document that this is broken code. For practical reasons it may be 
desirable to make sure this unsafe code works when optimization is disabled. 
In this case we need to document under what curcumstances we guarantee the 
code works.

Paul


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