[PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[Harald Anlauf]

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