This is the mail archive of the 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: *ping* - [Patch, Fortran] Coarray fixes for select type/associate and type of derived components

Dear Tobias,

This looks absolutely fine to me - good for trunk.

Thanks for the patch and for the overall co-array effort.


On 4 July 2014 08:02, Tobias Burnus <> wrote:
> Another somewhat early PING**2
>> On June 29, 2014, Tobias Burnus wrote:
>>> This patch fixes some issues with polymorphic coarrays. I still have to
>>> fix at least one issue.
>>> Fixed by the patch:
>>> a) The temporary pointer generated with SELECT TYPE has to be a coarray.
>>> That's fixed with the resolve.c patch. The comment is also bogus: The
>>> comment is correct â and gfortran correctly detects coindexed variables as
>>> selector. However, in the code in question, the selector is not coindexed
>>> but the variable in the coindexed section is.
>>> b) It doesn't make sense to try to initialize the temporary pointer of
>>> SELECT TYPE (or ASSOCIATE), thus we have to exclude it also in trans-decl.c
>>> c) As the temporary variable is internally a pointer, the assert in
>>> trans-array.c also has to accept a pointer â even though coarrays with token
>>> in the descriptor can only be allocatable. But for code like "a(1)[1])",
>>> "a(1)" is not longer a pointer â and one ends up having an akind of unknown.
>>> Instead of adding all kind of values, I simply removed the assert.
>>> d) In trans-intrinsic.c, one has a similar issue. We now avoid an ICE by
>>> checking whether the variable is set before accessing it.
>>> e) For caf(:)[i]%a, we had the dtype of the descriptor of "caf" instead
>>> of "...%a". That's now fixed.
>>> Build and regtested on x86-64-gnu-linux.
>>> OK for the trunk?
>>> Tobias
>>> PS: Still to be done for coarrays: Nonallocatable polymorphic coarray
>>> dummies. For those, the offset and the token is passed as additional
>>> argument â but that's not yet correctly handled with ASSOCIATE/SELECT TYPE.
>>> Also to be done are more type-conversion checks (beyond those which are
>>> implicitly checked by this patch) â and the handling of vector subscripts.

The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

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