Hi Tobias, > Consider: > > type t > integer, allocatable :: a > end type t > > type(t) :: var[*] > print *, allocated(var%a) > print *, allocated(var[1]%a) > end
what is the problem here? Can you elaborate? BTW: Intel accepts it, we (currently) accept it, my patch does not change anything. > I think pointer has a likewise issue. > It should be sufficient to get rid of the > attr.codimension. ??? > * * * > > Note regarding pointers: F2018:C1542 also does not > apply to intrinsics, cf. note below C1542 (quoted below). > > * * * > > By itself, I do not see why accessing the value of a > coindexed variable is a problem – just (de)allocating it should > cause problems. > > With pointers, undefined might be an additional issue. > > Thus, while > allocate( coindexed object ) > has issues and is invalid – all refs to F2018: > C950 (R932) An allocate-object shall not be a coindexed object. > > I do not see why > allocated ( ...) > should be invalid; in particular, just a a NULL value check is needed. > > Likewise for > associated ( ) > > Besides exceptions for polymorphic allocatables, I find: > > C1537 An actual argument that is a coindexed object shall not have a pointer > ultimate component. > > C1542 The actual argument corresponding to a dummy pointer shall not be a > coindexed object. > Note 1: Constraint C1542 does not apply to any intrinsic procedure because an > intrinsic procedure is defined in > terms of its actual arguments. > > For allocatables, there is: > "If the actual argument is a coindexed object with an allocatable ultimate > component, the dummy argument shall have the INTENT (IN) or the VALUE > attribute." I am afraid you lost me here. There are other PRs involving coarrays. Are you suggesting I should solve them all? Withdrawing the patch. Harald
