To: J3 J3/22-127 From: Mark LeAir Subject: Nvidia's Comments to the Fortran 202X CD Date: 2022-February-26 Reference: 19-150, 20-113r1, 20-120r1, 22-007 Introduction ============ We at Nvidia wish to put into the record the following concerns for the upcoming Fortran 202X standard. We hope that this paper will provide motivation for improvement of the multiple-subscript syntax and/or the selection process for features in future Fortran Standards. 1. Multiple-Subscript Syntax Our position at Nvidia is that we do not like the addition of the multiple-subscript (@) array syntax (9.5.3.2). We do not see many use cases for this syntax. The multiple-subscript syntax cannot be used directly with assumed-rank dummy arrays (the most likely use case) without a select rank construct which does not scale well for arrays that can have any number of dimensions. It will also be nontrivial to implement some of its edge cases. 1.1 No Assumed Rank Dummy Array Support The multiple-subscript syntax was added to support rank agnostic arrays. Fortran 2018 has rank agnostic arrays in the form of assumed rank dummy arrays. However, assumed rank dummy arrays cannot be directly used without a select rank construct. Furthermore, the addition of the multiple-subscript syntax does not add direct subscripting for assumed rank dummy arrays. One still has to use a select rank construct for each assumed rank dummy array in an array expression. This does not scale well if the array expressions can operate on a variety of dimensions. The multiple-subscript syntax does not help this use case. Below illustrates this shortcoming using just assumed rank dummy arrays. Example 1: Let us say we want to compute b1 = b1 + b2 + b3 (where b1, b2, and b3 are all assumed rank dummy arrays). Let us also say the programmer knows that the rank of the arrays must be rank 2 or 3. Today, they would have to write something like the following: subroutine add_arrays(b1, b2, b3) real :: b1(..), b2(..), b3(..) select rank (b1) rank(2) select rank(b2) rank(2) select rank(b3) rank(2) b1 = b1 + b2 + b3 rank default error stop 'expected rank 2 for b3' end select rank default error stop 'expected rank 2 for b2' end select rank(3) select rank(b2) rank(3) select rank(b3) rank(3) b1 = b1 + b2 + b3 rank default error stop 'expected rank 3 for b3' end select rank default error stop 'expected rank 3 for b2' end select rank default error stop 'unexpected rank for b1' end select end subroutine add_arrays 1.2 A Complicated Edge Case The multiple-subscript syntax presents a hard case to implement when two (or more) vectors appear in a multiple-subscript and their lengths cannot be known at compilation time. The mapping from their elements to the dimensions of the array will not be known until execution, and the generated code will have to essentially merge them together as if they had been concatenated in an array constructor (see example below). Example 2: subroutine method1(a, v1, v2, j, k) real :: a( :, :, :, : ) integer :: v1(:), v2(:) integer :: j, k a(@v1(j:j + 1), @v2(k:k + 1)) = 0 end subroutine method1 Under the hood, the compiler will have to treat the multiple- subscript expression, a(@v1(j:j + 1), @v2(k:k + 1)) = 0, like the following Fortran code: integer, allocatable :: v3(:) integer :: sz1, sz2 sz1 = (((j + 1) - j) + 1) sz2 = (((k + 1) - k) + 1) allocate(v3(sz1 + sz2)) do i=1, sz1 v3(i) = v1(j + i) enddo do i=1, sz2 v3(sz1 + i) = v2(k + i) enddo a(@v3) = 0 ! a(v3(1), v3(2), v3(3), v3(4)) = 0 Example 2 illustrates that the multiple-subscript syntax in its current state is just "syntactic sugar" for indexing a known ranked array with a vector. Without direct support for assumed rank dummy arrays, we do not feel adding multiple-subscript syntax to the language justifies the amount of compiler implementation needed to support the feature. 2. Changes to IOMSG=, ERRMSG=, and internal output We at Nvidia are not comfortable with the change in Fortran 202X for IOMSG=, ERRMSG=, and internal output in the context of (allocatable) deferred-length character scalar variables (4.3.3 paragraph 3, 9.7.5 paragraph 2, 12.11.6 paragraph 1). In particular, the case where an implementation is now required to silently reallocate an (already allocated) allocatable object. Prior to this change, the explanatory message variable was truncated or padded to the length of the already allocated character variable. The 202X modification changes the semantics of existing programs and implementations. Conclusion ========== This paper addresses concerns that Nvidia has with the Fortran 202X Standard CD. It described two concerns with the multiple- subscript syntax. The first concern is the lack of added support for assumed rank dummy arrays. The second concern is the amount of compiler implementation required for certain edge cases like the one described in Example 2. Paper 19-150 acknowledges that further investigation is needed for assumed rank dummy arrays. But no further investigation appears to have happened. If support for assumed rank dummy arrays could have been added, it would address the select rank problem in Example 1 and help justify the amount of compiler implementation needed to satisfy edge cases like the one described in Example 2. In planning next generation Fortran features, we hope the Fortran Committee can carefully select features that cover a variety of use cases. We also hope the committee can consider the amount of compiler implementation needed for these features. In the case of multiple- subscript syntax, the committee left the obvious use case, assumed rank dummy arrays, on the table. When considering a feature that has a use case that it does not satisfy, it would be better to delay rolling out the feature until all known use cases are investigated and addressed. The changes to IOMSG=, ERRMSG= and internal output also concern us. We also hope the committee will carefully consider the impact on existing programs and implementations when they consider changes to existing language constructs.