No warning for nonstandard initialization of an array

Developer Software Tools Intel® Fortran Compiler
1

Although it seems like it should be standard,  I am pretty sure that the shape of the LHS has to match the RHS in a declaration.  I think it is a good extension as that seems silly when the shape of the LHS is fixed; and because there is no such limitation with a DATA statement; but I think if I am

using “ifx -stand f18  xx.F90”  I should be getting a warning about line #8.

program demo_clip
implicit none
integer :: ii(2,3)
! everyone takes a DATA statement
data ii/10,20,30,40,50,60/
#ifdef __INTEL_COMPILER
! ifort -stand f18 xx.f90 does not produce warning
integer :: jj(3,4)=[1,2,3,4,5,6,7,8,9,10,11,12]
#elif __GFORTRAN__
! gfortran requires a reshape
integer :: jj(3,4)=reshape([1,2,3,4,5,6,7,8,9,10,11,12],shape(jj))
#endif
   call printi('ii=',ii)
   call printi('jj=',jj)
contains
subroutine printi(title,a)
implicit none
! print small 2d integer scalar, vector, matrix in row-column format
character(len=*),intent(in) :: title
integer,intent(in)          :: a(..)
character(len=*),parameter  :: all='(" ",*(g0,1x))'
character(len=20)           :: row
integer,allocatable         :: b(:,:)
integer                     :: i
   write(*,all,advance='no')trim(title)
   ! copy everything to a matrix to keep code simple
   select rank(a)
   rank (0); write(*,'(a)')' (a scalar)'; b=reshape([a],[1,1])
   rank (1); write(*,'(a)')' (a vector)'; b=reshape(a,[size(a),1])
   rank (2); write(*,'(a)')' (a matrix)'; b=a
   rank default; stop '*printi* unexpected rank'
   end select
   ! find how many characters to use for integers
   write(row,'(i0)')ceiling(log10(real(maxval(abs(b)))))+2
   row='(" > [",*(i'//trim(row)//':,","))' ! use this format to write a row
   do i=1,size(b,dim=1)
      write(*,fmt=row,advance='no')b(i,:)
      write(*,'(" ]")')
   enddo
   write(*,all) '> shape=',shape(a),',rank=',rank(a),',size=',size(a)
   write(*,*)
end subroutine printi
end program demo_clip

2

Dear Intel Support Team,

You may perhaps view this as a feature request since the Fortran standard does not require, per my read, to detect and report the nonconformance e.g., no named constraint that I can find toward the semantics, “If the entity does not have implied shape, initialization shall be scalar or have the same shape as the entity.”

Intel Fortran appears to detect and report in the case of intrinsic assignment, but not with initialization, for example:

block
      integer :: jj(3,4) = [1,2,3,4,5,6,7,8,9,10,11,12]
   end block
   block
      integer :: jj(3,4)
      jj = [1,2,3,4,5,6,7,8,9,10,11,12]
   end block
end

C:\temp>ifx /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

p.f(6): error #6366: The shapes of the array expressions do not conform.   [JJ]
      jj = [1,2,3,4,5,6,7,8,9,10,11,12]
------^
compilation aborted for p.f (code 1)
3

You are correct that the shape of the LHS has to match the RHS in a declaration. In the code you provided, the declaration of jj is incorrect because the shape of the LHS does not match the shape of the RHS. While it may compile without errors using some compilers, this is not valid Fortran.

To initialize jj with the same values as ii, you can use the reshape function, as you did in the #elif __GFORTRAN__ block. This will make the shape of the LHS match the shape of the RHS, which is necessary for valid Fortran syntax.

4

I agree that this should be an error The standard says:

4 If initialization appears for a nonpointer entity,
• its type and type parameters shall conform as specified for intrinsic assignment (10.2.1.2);
• if the entity has implied shape, the rank of initialization shall be the same as the rank of the entity;
• if the entity does not have implied shape, initialization shall either be scalar or have the same shape as the entity.

5

So the standard does explicitly define it as non-standard as I was initially assuming;  but it seems a totally reasonable extension as there is no problem with initializing the same data with a DATA statement when the shape is known.  It definitely gets a bit more confusing if passing such a vector as an argument or in other cases but in the declarations it seems much cleaner than a RESHAPE to me.  So I was just hoping for a warning message;  is the standard requiring it be an error?

6

No, the standard does not require the ability to diagnose this usage, as it is neither a numbered syntax rule nor a constraint..

7

I submitted an issue on this, CMPLRLLVM-45137. I asked that a warning message be printed when the -stand fxx compiler option is used.

8

Look for a warning message from the 2024.2 compilers that are planned for release in mid-2024.