Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28446 Discussions

Type parameter inquire (F2018: 9.4.5)

Harald1
New Contributor II
659 Views

ifort/ifx-21.3 do not accept type parameter inquiries as described in F2018 section 9.4.5.

Example:

character(len=5)   :: str
integer, parameter :: n = len (str)      ! accepted (ok)
integer, parameter :: i = kind(str)      ! accepted (ok)
integer, parameter :: j = str% kind      ! not accepted
integer, parameter :: k = str% len       ! not accepted
integer, parameter :: l = str(1:3)% len  ! not accepted
integer, parameter :: m = str(1:3)% kind ! not accepted
end

 I get:

%ifort ifort-inquiry.f90
ifort-inquiry.f90(4): error #7169: Bad initialization expression.   [STR]
integer, parameter :: j = str% kind      ! not accepted
--------------------------^
ifort-inquiry.f90(5): error #7169: Bad initialization expression.   [STR]
integer, parameter :: k = str% len       ! not accepted
--------------------------^
ifort-inquiry.f90(6): error #7169: Bad initialization expression.
integer, parameter :: l = str(1:3)% len  ! not accepted
--------------------------^
ifort-inquiry.f90(7): error #7169: Bad initialization expression.
integer, parameter :: m = str(1:3)% kind ! not accepted
--------------------------^
compilation aborted for ifort-inquiry.f90 (code 1)

 Expected: no output (everything is accepted).

Note: lines 4 and 5 are accepted e.g. by gfortran 9+, but (not yet) lines 6 and 7.

 

Thanks,

Harald

 

0 Kudos
4 Replies
Mark_Lewy
Valued Contributor I
615 Views

Interesting, so I wondered what would happen if you used variables instead of parameters:

program type_params
    implicit none
    character(5) :: str
    integer :: o, p, q, r, s, t

    print *, 'Hello World'
    o = len (str)
    p = kind(str)
    q = str% kind
    r = str% len
    s = str(1:3)% len
    t = str(1:3)% kind

    print*, o, p, q, r, s, t
end program type_params

 

This is the output I get:

Hello World
5 1 1 5 -1525680944 1

It looks like using the len inquiry on a substring is not working as expected either.

ifort 2021.3 x64

 

0 Kudos
andrew_4619
Honored Contributor II
605 Views

The parameter case on line 4 and 5 should be good as it is a "constant expression" I am not sure about the sub-string case. Hopefully someone from Intel will pick up this bug.

0 Kudos
FortranFan
Honored Contributor II
592 Views

At first glance, the code in the original post looks conforming.  Hopefully Intel staff can pick it from here.

 

IFORT response to line 4 (and may be 7) is surprising especially because a similar situation with parameterized derived types (PDTs) I had reported was resolved by Intel sometime back.  A processor can superficially treat the CHARACTER intrinsic type as if a "pseudo" PDT with one kind-type parameter labeled KIND and one length-type parameter named LEN and thus support some of these syntactic sugar introduced starting Fortran 2003.

0 Kudos
Barbara_P_Intel
Moderator
554 Views

Thank you, gentlemen, for all this information. I filed a bug report, CMPLRIL0-34090, on these issues with type parameter inquire. I'll let you know its progress to a fix.



0 Kudos
Reply