Invalid sequence association when passing substring

[Dave_Allured]

In the following test, the main program passes substrings from a character array, via the explicit interface of sub1. Sub1 then passes on its input array to sub2 via an implicit interface. I test two variations of the actual argument in the call statements for sub2:

[fortran]! Version string14.f90, 2012-feb-21 subroutine sub2 (s2) character(len=*) s2(*) print "(' ""', a, '""')", s2(1:4) end subroutine sub2 module mod1 contains subroutine sub1 (s1) character(len=*), intent(in) :: s1(:) print *, 'len (s1) = ', len (s1) print *, 'shape (s1) = ', shape (s1) print *, 'Pass by reference to whole array:' call sub2 (s1) print *, 'Pass by reference to first array element:' call sub2 (s1(1)) end subroutine sub1 end module mod1 program str_test use mod1 character(len=3) s(4) s = (/ '123', '456', '789', 'ABC' /) call sub1 (s(:)(1:2)) end program str_test [/fortran]
I would expect to get the same results either way, by sequence association, but there is a surprise:

[bash]mac56:~/bugs/string-array 83> ifort string14.f90 mac56:~/bugs/string-array 84> ./a.out len (s1) = 2 shape (s1) = 4 Pass by reference to whole array: "12" "45" "78" "AB" Pass by reference to first array element: "12" "34" "56" "78" [/bash]
Is this valid Fortran? Is this a compiler bug?

I get the same results with two versions of Intel Fortran. On Mac OS 10.6.8:
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100806 Package ID: m_cprof_p_11.1.089

On Mac OS 10.7.3 (Lion):
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.1.246 Build 20111011

Also note that the following compilers get the "right" answer:
gfortran version 4.5.2 on Mac
pgf90 version 8.0-2 on Linux

And Sun Fortran 95 version 8.3 on Linux gets the "wrong" answer, same as Intel Fortran.

Thanks for any insights about this.

--Dave A.

[Dave_Allured]

RO, in reply #14 you requested output from other compilers.

Output from Intel fortran version 11.1.089 on Mac OS 10.6.8:

[bash]Address of s1(1)(1:1) = 00000001000A11C0 Address of s1(1)(2:2) = 00000001000A11C1 Address of s1(2)(1:1) = 00000001000A11C3 Address of s1(2)(2:2) = 00000001000A11C4 Address of s1(3)(1:1) = 00000001000A11C6 Address of s1(3)(2:2) = 00000001000A11C7 Address of s1(4)(1:1) = 00000001000A11C9 Address of s1(4)(2:2) = 00000001000A11CA [/bash]
As you predicted, the addresses are not contiguous. This is no surprise to me, and also not relevant to the original question for the reasons I gave in reply #16. It is interesting, but not relevant. Restating briefly, any compiler that stores s1 non-contiguously is required to make a contiguous copy before calling sub2 by either of the demonstrated methods.

I will probably be out of the office tomorrow. I will be able to rejoin the Quest for Truth by Monday if not sooner. Have a good weekend everyone.

--Dave

[Dave_Allured]

Okay, I took a closer look at 12.5.2.4, paragraph 13 (F2008) which Repeat Offender quoted in reply #3. Requoting:

"If the actual argument is a coindexed scalar, the corresponding dummy argument shall be scalar. If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array."

Repeat Offender claims that sentence 2 does not permit the array element designator s1(1) to be used as the start of a sequence association of more than one element, because s1 is an assumed-shape array. This is also the essence of Steve Lionel's objection.

I previously claimed in reply #20 that the clause "unless the actual argument is default character" overrules the rest of this sentence when interpreted literally, because of "OR" association. Therefore there is no restriction on this usage of an assumed-shape array, resulting in a valid sequence association and a requirement for the compiler to make a complete contiguous copy of s1.

However, it gets more interesting. The two clauses "unless the actual argument is default character, of type character with the C character kind" were added to the standards between Fortran 95 and Fortran 2003. So this might mean that my example was invalid Fortran according to Fortran 90 and 95 standards, but legal according to Fortran 2003 and 2008.

I think the reality is that this revision created an unintentional bug in the standard, an exception to the original F90/F95 restriction for entities that can not be guaranteed contiguous. This has made fertile ground for disagreement over the interpretation. I have not researched the history beyond one reference which said merely that the clauses were added to simplify C interoperability with Fortran strings. That does not sound like a good reason to change legacy support rules for argument association.

My present conclusion is that the original example using call sub2 (s1(1)) is not valid code in the context of combined Fortran standards from F90 through F2008. Also, Intel Fortran and the other three cited compilers are all working correctly because they all print the correct sequence association value for the first element from call sub2 (s1(1)). The first element is all that is required according to this revised interpretation.

Further comments are welcome, especially on the possibility of a mistake in the present standard.