2

Consider the following code that attempts to create a coarray derived type containing an array of variable-length allocatable character types.

program testCoarrayJaggedArray

implicit none

integer :: i
type                                :: CharVec_type
    character(:), allocatable       :: record
end type

type                                :: List_type
    type(CharVec_type), allocatable :: Item(:)
end type

type(List_type)                     :: List[*]

if (this_image()==1) then
    allocate( List%Item(num_images()) )
    do i = 1, num_images()
        allocate( character(63) :: List%Item(i)%record )
        write(List%Item(i)%record,*) i
        List%Item(i)%record = "King" // trim(adjustl(List%Item(i)%record))
    end do
    sync images(*)
else
    sync images(1)
    allocate( List%Item( size(List[1]%Item(:)) ) )
    do i = 1, size(List%Item(:))
        allocate( character( len(List[1]%Item(i)%record) ) :: List%Item(i)%record )
        List%Item(i)%record = List[1]%Item(i)%record
        write(*,*) this_image(), List%Item(i)%record
    end do
end if

end program testCoarrayJaggedArray

Intel's ifort 2018 in debug mode, shared-memory coarray, complains about several aspects of this code. Here is the first one:

ifort /debug /Qcoarray=shared /standard-semantics /traceback /gen-interfaces /check /fpe:0 main.f90 -o run.exe
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.185 Build 20180210
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.

main.f90(30): error #6457: This derived type name has not been declared.   [CHARACTER]
        allocate( character( len(List[1]%Item(i)%record) ) :: List%Item(i)%record )
------------------^
main.f90(30): error #8235: If type specification appears, the type and kind type parameters of each object being allocated must be the same as type and kind type parameters of the type specification.   [RECORD]
        allocate( character( len(List[1]%Item(i)%record) ) :: List%Item(i)%record )
---------------------------------------------------------------------------^
compilation aborted for main.f90 (code 1)

Is this code non-standard Fortran? In particular the line that allocates a character type using the length of the corresponding character on the first image:

allocate( character( len(List[1]%Item(i)%record) ) :: List%Item(i)%record )
francescalus
  • 30,576
  • 16
  • 61
  • 96
Scientist
  • 1,767
  • 2
  • 12
  • 20

1 Answers1

1

Regardless of the conformance of the program, the first error message is gibberish: character is not a valid name for a derived type. At the least, this should be reported to Intel support as a quality of implementation issue.

Now, is the code conforming? Rather than answer that, I'll look at the following program:

integer :: i[*]
character(:), allocatable :: x

i=1
allocate(character(i[this_image()]) :: x)

end

When I compile with ifort 18.0.2

test.f90(5): error #6457: This derived type name has not been declared.   [CHARACTER]
allocate(character(i[this_image()]) :: x)
---------^
test.f90(5): error #8235: If type specification appears, the type and kind type parameters of each object being allocated must be the same as type and kind type parameters of the type specification.   [X]
allocate(character(i[this_image()]) :: x)
---------------------------------------^
compilation aborted for test.f90 (code 1)

Let's look at what should happen to this program.

We can probably all agree that the only contentious line is the allocation statement, and the only part of that which is tricky is (again) the length type parameter for the type specification. So, is i[this_image()] a valid type parameter here?

It's a scalar integer expression and it's defined. We just need to determine whether any other restriction applies which is violated. There is none in Fortran 2008.

The compiler should not reject this program.

As a workaround for the program of the question: create a non-coarray temporary copy of the length expression to use in the allocation statement.

francescalus
  • 30,576
  • 16
  • 61
  • 96
  • thank you. That's actually what I ended up doing as a workaround solution. But as you said, this code appears to be standard-conforming, to my knowledge. I have posted this on Intel forum and will relay Intel's response here if they provide any. – Scientist Jun 12 '18 at 22:16