This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)


Hi,

On Thu, 14 Jul 2011, Richard Guenther wrote:

> Sure ;)  What the middle-end currently lacks is explicit tracking of 
> what escapes through a function return as opposed to what escapes 
> somewhere else.  Once that is implemented a flag on the PARM_DECL that 
> tells it to use Fortran dummy argument rules is easy to implement (but 
> we have issues when that dummy argument is an array descriptor and the 
> dummy argument rules also apply to the actual array data - as opposed 
> to, I presume, a dummy argument of fortran aggregate type with a pointer 
> member).

And the latter is also why such a flag/attribute needs to be ultimately 
placed on the type, so that we can form pointers to such parm_decls (or 
even members of array descriptors) without loosing the special guarantees, 
ala "not clobbered by calls".  That or flags on the MEM_REF (which 
magically needs to be set then, most probably again, by tracking such flag 
from the PARM_DECL, through types to the MEM_REF).

> It's on my list to solve that function-return-escape thing, but as usual
> my list of things to implement is rather large ;)
> 
> For the record, the current way of using C restrict works reasonably
> well and I don't think we will gain very much in real-world performance
> if not using it

Did you really want to say this?  Because I'm very sure we actually loose 
very much in real-world performance if we wouldn't be using it (or some 
alterntive that is specified somewhat cleaner).


Ciao,
Michael.


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