- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't argue with the Fortran experts on this Forum!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree that ifort has a bug here. I even helped write this part of the standard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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) )]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> 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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't argue with the Fortran experts on this Forum!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The scoping issue is indeed resolved.
The other issues referred to by @FortranFan seem to be still open; likely tracked elsewhere.
Thanks,
Harald
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page