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

Scoping issue with integer type-spec in implied do

Harald1
New Contributor II
831 Views

Ifort rejects the following code, although it should be valid F2018:

program foo
  use iso_fortran_env, only : k => real_kinds
  implicit none
! integer(8) :: i ! OK
  real(8)    :: i ! not OK
  integer, parameter :: n = size(k)
  integer, parameter :: q(n) = [(kind(i), integer(2) :: i = 1, n)]
  print *, q
end program foo

I get:

ifort_implied_do_index.f90(7): error #6325: An integer data type is required in this context.   [I]
  integer, parameter :: q(n) = [(kind(i), integer(2) :: i = 1, n)]
--------------------------------------------------------^
compilation aborted for ifort_implied_do_index.f90 (code 1)

Commenting the declaration of i, or activating the integer variant, make the code compile and execute correctly.

The Cray compiler 14.0 accepts the code as expected.

Thanks,

Harald

 

0 Kudos
1 Solution
Barbara_P_Intel
Moderator
767 Views

Can't argue with the Fortran experts on this Forum! I filed a bug report, CMPLRLLVM-42129. I'll let you know when it's fixed.



View solution in original post

0 Kudos
8 Replies
Steve_Lionel
Honored Contributor III
823 Views

I agree that ifort has a bug here. I even helped write this part of the standard.

0 Kudos
FortranFan
Honored Contributor II
809 Views

@Harald1 ,

Re: "Commenting the declaration of i, or activating the integer variant, make the code compile and execute correctly," are you sure about the "execute correctly" part?  I have several support requests open with Intel for a while now about the resulting named constant array, "q" in your case, having unexpected values.

0 Kudos
Harald1
New Contributor II
757 Views

The above testcase appears to execute correctly, but it doesn't test much.

I believe you thought about code like:

program foo
  use iso_fortran_env, only : k => real_kinds
  implicit none
  integer, parameter :: n = size(k)
  print *, [(precision(real(1,kind=k(i))), integer :: i = 1, n)]
end program foo

This erroneously prints:

           6           6           6

You will likely expect e.g. "6 15 31", which I can get with a small modification from NAG.

 

0 Kudos
FortranFan
Honored Contributor II
748 Views

@Harald1 ,

Yes,  I didn't read your code carefully enough, I simply presumed it was similar to 

 

   use iso_fortran_env, only : ik => integer_kinds
   integer, parameter :: q(*) = [( kind(int(1,kind=ik(i))), i = 1, size(ik) )]
   print *, q
end

 

and for which the Intel Fortran compiler output is unexpected:

 

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

Microsoft (R) Incremental Linker Version 14.33.31630.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 1 1 1 1

C:\temp>

 

I suspect the output of the program with NAG compiler of the same code will be different? and perhaps along the lines of "1 2 3 4"?

 

But of course with a Fortran 2018 processor, I would have the same line as follows but it appears from the NAG website, that compiler doesn't yet support the topic of your title, the type-spec in the implied-do so you may not be able to test that aspect with NAG yet.

   integer, parameter :: q(*) = [( kind(int(1,kind=ik(i))), integer :: i = 1, size(ik) )]

 

0 Kudos
Harald1
New Contributor II
712 Views

> I suspect the output of the program with NAG compiler of the same code will be different? and perhaps along the lines of "1 2 3 4"?

Well, it depends...

With default options I get your expected "1 2 3 4", but with -kind=byte I obtain "1 2 4 8".

 

0 Kudos
Barbara_P_Intel
Moderator
768 Views

Can't argue with the Fortran experts on this Forum! I filed a bug report, CMPLRLLVM-42129. I'll let you know when it's fixed.



0 Kudos
Barbara_P_Intel
Moderator
525 Views

The invalid error message is gone! Try the new ifort and ifx that are part of oneAPI HPC Toolkit 2023.1. It was released this week.



0 Kudos
Harald1
New Contributor II
493 Views

The scoping issue is indeed resolved.

The other issues referred to by @FortranFan seem to be still open; likely tracked elsewhere.

Thanks,

Harald

 

0 Kudos
Reply