Compiler bug or feature?

I have put together the example below to illustrate FTN95 behaviour that surprised me. Look at the commented statement that assigns values to the dest array. FTN95 accepted this without warning and implemented it as though the statement was:

dest(ii(1): jj(1): -1) = 6

gFORTRAN however, does not accept the original statement and, I think correctly, reports an error 'Array index must be scalar'.

So, is the FTN95 behaviour here a bug or a feature?

Here is the code:

integer, dimension(10) :: dest integer, dimension(2) :: ii integer, dimension(2) :: jj

dest = 0

ii(1) = 4 ii(2) = 9 jj(1) = 2 jj(2) = 7

dest(ii: jj: -1) = 6 ! What does this do?

I am guessing that this is not valid Fortran so FTN95 should report a compilation error.

However, it is treating it as

dest(ii(1): jj(1): -1) = 6

which in this context is

dest(4: 2: -1) = 6

which means

dest(4) = 6; dest(3) = 6; dest(2) = 6

i.e start at 4 and step to 2 in steps of -1.

I agree FTN95 should ideally be providing a compiler error with the above code.

However, arrays can be used as indices like in the following example, so there is a need to ensure such array indices are supported if any 'fix' is implemented.

INTEGER I(3)
REAL A(6)

A = 0.0

I = (/2, 4, 6/)  ! Sets I(1)=2, I(2)=4, I(3)=6
A(I) = 6.0       ! Sets A(2)=6, A(4)=6, A(6)=6

The following extracts from section 6.5.3.1 of the Fortran Standard lead one to conclude that the subscript expression 'ii: jj: -1' is invalid, since 'dest', 'ii' and 'jj' have been declared as integer arrays.

R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ]

R619 subscript is scalar-int-expr

This issue has now been fixed for the next release.