Intel compiler: Funny bug with namelist, non-standard code and implicit none

[Harald1]

Consider:

implicit none
namelist /NML/ x, m, q
real :: x, m
integer :: q
x = 1.0
m = 2.0
q = 3
write(*, nml=NML)
end

This code in in disagreement with F2018, Section 8.9, which requires the implicit declaration in the namelist statement and the subsequent explicit declaration to agree if it has not been declared before.

(I think the "implicit none" prohibits the implicit declaration.)

gfortran silently accepts the code, NAG rejects it.

But Intel 2021.1 does the following:

% ifort pr98686.f90 && ./a.out
&NML
X = 1.000000 ,
M = 2.000000 ,
Q = 3
/

% ifort pr98686.f90 -stand && ./a.out
pr98686.f90(2): warning #8586: Implicit type is given to allow out-of-order declaration. Non-standard extension. [X]
namelist /NML/ x, m, q
-----------------^
pr98686.f90(2): warning #8586: Implicit type is given to allow out-of-order declaration. Non-standard extension. [M]
namelist /NML/ x, m, q
--------------------^
pr98686.f90(2): warning #8586: Implicit type is given to allow out-of-order declaration. Non-standard extension. [Q]
namelist /NML/ x, m, q
-----------------------^
pr98686.f90(3): warning #8125: This type conflicts with a previous implicit typing of a namelist group object with the same name, it is prohibited by Fortran standard. [M]
real :: x, m
----------------^
pr98686.f90(4): warning #8125: This type conflicts with a previous implicit typing of a namelist group object with the same name, it is prohibited by Fortran standard. [Q]
integer :: q
-------------^
&NML
X = 1.000000 ,
M = 1073741824,
Q = 4.2038954E-45
/

Thus only a warning is issued, not an error, and the result changes!

[FortranFan]

@Harald1 ,

Ref: https://groups.google.com/g/comp.lang.fortran/c/Skryv65Rznk/m/jNQatlumDAAJ

Glad you are able to post here now.

As you were informed earlier, you can consider warn stderrors in the interim (because it's not as though IFORT will overnight have enhancements - these things take a lot of time - months, years, etc, if at all they make it!):

https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/compiler-diagnostic-options/warn.html

And hopefully you can engage with Intel support here toward better support you seek with NAMELIST and other aspects of the language and/or compiler options.

Now that Intel oneAPI toolkits effectively give you free access to IFORT compiler and other HPC libraries, one would think purchasing support subscription will give you better chances of influence with the Intel compiler team.

[Harald1]

I'm somewhat reluctant to generally enable -warn stderrors because compilers sometimes have false positives, so that in turn one needs to disable these (false positives).

[Steve_Lionel]

I'm astonished that ifort gave only a warning here, because in other contexts it does not allow later type declarations that conflict with implicit type. For example:

D:\Projects>type t.f90
subroutine foo (x)
implicit none
integer q(x)
integer x
end
D:\Projects>ifort -c t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1.2 Build 20201208_000000
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

t.f90(4): error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.   [X]
integer x
--------^
compilation aborted for t.f90 (code 1)

I remember having discussions about allowing out-of-order declarations as an extension, which some compilers (such as gfortran) do, and our opinion was that we were not going there. I wonder why NAMELIST was exempted.

That said, the code is non-standard and a compiler is free to do anything it wants with it. Not a bug.

[Harald1]

Hi Steve,

the next release of gfortran will actually reject the code originally posted with an

Error: Symbol 'q' in namelist 'nml' at (1) must be declared before the namelist is declared.

I guess my colleagues who originally were affected by this will be delighted to have this caught.

[Steve_Lionel]

gfortran is doing the right thing, though I can guarantee they will get tons of complaints. I do think it is inconsistent of Intel Fortran to allow this by default.