IFX 2025.0.0 -data object with a coarray component can now be an array- only partially implemented

[Michael_S_17]

From the New Features list at https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-0/new-features.html we can find this new Fortran 2023 feature:

• A data object with a coarray component can now be an array, and it can be allocatable (arrays of coarrays).

This new Fortran 2023 feature is only partially implemented with ifx 2025.0.0 yet: It does work well for data objects that are variables, but not if the data object is a component. See this quote from Modern Fortran explained, Fortran 2023 edition, chapter 23.6.1, p.455:

“…, Fortran 2018 requires that a variable or component that is of a type with a coarray ultimate component be a non-pointer non-allocatable non-coarray scalar. Fortran 2023 permits such a variable or component to be an array and/or allocatable, ...”

See also the simple test case below:

program main
end program main


module test
implicit none
private

type, public :: a
  private
  integer, public, allocatable, dimension(:), codimension[:] :: coarray
end type a

type, public :: b
  private
  type(a), public, allocatable, dimension(:) :: channels_1 ! compile time error 
  ! with ifx 2025.0.0:
  ! error #8474: A data component whose type has a coarray potential subobject 
  ! component must be a nonpointer nonallocatable scalar.
end type b

type(a), public, allocatable, dimension(:) :: channels_2 ! compiles and runs 
  ! perfectly with ifx 2025.0.0

end module test

Regards

[Michael_S_17]

Thanks very much for inquiring into this and your feedback on this. Indeed, the issue was that C753 constraint in the Fortran 2023 standards text. Fortunately, that mistake is already corrected with this edit ( https://j3-fortran.org/doc/year/25/25-100.txt ), number F23/009 :

“... ANSWER:
No, this constraint was accidentally overlooked when extending types
with coarray components to be subobjects of arrays and allocatables.
An edit is provided to correct this mistake.
EDIT to N2218 (Fortran 2023 FDIS):
[79:constraint C753] In subclause
Delete this constraint, which begins
“C753 A data component whose type has a coarray”
[80:After NOTE 1] Insert new NOTE
“NOTE 1.5
A data component whose type has a coarray potential subobject
component cannot be a coarray or a pointer, see constraint C825.”
{C825 says “An entity whose type has a coarray potential subobject…”
and components are certainly entities. We specifically wrote “entity”
instead of “named variable” to cover the component case.
I prefer to say it once and refer to it.}

SUBMITTED BY: John Reid & Reinhold Bader

HISTORY: 23-210 m231 Submitted
23-210r1 m231 Revised
23-210r2 m231 Passed as amended by J3 meeting 231.
”

See also the recent short discussion here: https://fortran-lang.discourse.group/t/fortran-2023-an-array-or-allocatable-object-may-have-a-coarray-component/8877/3.

Regards

[Steve_Lionel · Accepted solution]

I'll note that interpretation 23/009 has not yet been approved into a corrigendum, though I have long noted that Intel is very slow at implementing changes from corrigenda.

[Michael_S_17]

Rationale for the Fortran 2023 feature -data object with a coarray component can now be an array-

These days we must be future-oriented: Ultra Accelerator Link (UALink), Ultra Ethernet Consortium (UEC), FPGAs, and anything else that will directly support PGAS (e.g. Fortran coarray remote assignments) and also massively increase the hardware parallelism available in the foreseeable future. The demands for new forms of parallel algorithms to address these new types of hardware will come, and we must tackle that today already; So, how should parallel programming look like in the impending future? I am trying to give an early answer to this question with my repo here: https://github.com/MichaelSiehl/Spatial_Fortran_1

With Fortran we can use standard OOP semantics to implement distributed objects using derived types with coarray components (since Fortran 2008). So in practice we can already use distributed objects to implement parallelism. The Fortran 2023 standard brings this to the next level by allowing us to implement a collection class comprising a number of distributed objects, which is the topic of this request.

My practical application for this is the implementation of a channel class. I am already using techniques for single image asynchronous programming with Fortran (still experimental), i.e. running multiple “threads” on a single coarray image. This requires multiple channel objects on each coarray image. A Fortran 2023 collection class for these multiple distributed objects (e.g. channels) will allow to implement additional codes for managing the collection of distributed objects and will bring these codes away from the parallel loop (that’s where they are currently in my coarray programming projects).

Hope this helps you to value this new Fortran 2023 feature.

Regards