I was testing the new intrinsic function IS_CONTIGUOUS of Fortran 2008 and I found that gfortran 9.1.1 and ifort 18.104.22.168 give different results for the real part of a complex array.
Here is the example:
program testing implicit none complex(8) :: ac(1000) ac(:) = (1.0_8,1.0_8) write(*,*) 'real part is contiguous:',IS_CONTIGUOUS(ac(:)%re) end program
$ gfortran contiguous.f90 $ ./a.out real part is contiguous: F $ ifort contiguous.f90 $ ./a.out real part is contiguous: T
I tested this with NAG, and it also gives F for the real part being contiguos. I am not sure whether this is defined by the standard, whether the array of the real parts of a contiguous array has to be itself contiguous. The Fortran 2008 standard only states in 9.4.4:
If complex-part-designator is designator %RE it designates the real part of designator . If it is designator %IM it designates the imaginary part of designator. The type of a complex-part-designator is real, and its kind and shape are those of the designator, which can be an array or scalar.
So nothing about contiguousness, and then it is up to the compiler.
I suggest you submit a support request with Intel at https://supporttickets.intel.com/servicecenter?lang=en-US and have Intel Fortran team take a look.
Note the Fortran standard says, "An array designator is simply contiguous if and only if it is .. an array section .. that is not a complex-part-designator," And if you look at the layout of data in memory of your 'ac' array, you will notice the "ac(:)%re" cannot possibly be contiguous. Unless the 'ac(:)%re' reference results in an array temporary, it's mind-boggling how the intrinsic "IS_CONTIGUOUS" can return T.
My hunch is Intel Fortran has a bug; other than above, another evidence is the C_LOC intrinsic from ISO_C_BINDING returns the same address for 'xx%re' and "xx%im" parts of an object 'xx' of COMPLEX type. So what "IS_CONTIGUOUS" function may be seeing is only the whole array 'ac' and it perhaps returns an answer for such an array instead of the real-part of the array.
I may be wrong about all this, it may be best for you to work this out with Intel Fortran team.