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
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)
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.
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.
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.
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?