info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intel compiler: Funny bug with namelist, non-standard code and implicit none
171 views
Skip to first unread message
Harald Anlauf
Jan 17, 2021, 4:53:12 PM1/17/21
to
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!
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!
Robin Vowels
Jan 18, 2021, 3:13:49 AM1/18/21
to
JRR
Jan 18, 2021, 9:39:25 AM1/18/21
to
Am 17.01.21 um 22:53 schrieb Harald Anlauf:
That's interesting, I only have the beta version of intel oneAPI installed,
Version 2021.1 Beta Build 20200827
but this rejects your code with an error when using the -stand flag,
as does ifort v20.
I failed to install the official oneAPI release remotely, and haven't
been to the office this year. On Wednesday, I will, however, and
hopefully then I can test.
--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany
>
> -------------^
> &NML
> X = 1.000000 ,
> M = 1073741824,
> Q = 4.2038954E-45
> /
>
> Thus only a warning is issued, not an error, and the result changes!
>
Happy new year, Harald!
> -------------^
> &NML
> X = 1.000000 ,
> M = 1073741824,
> Q = 4.2038954E-45
> /
>
> Thus only a warning is issued, not an error, and the result changes!
>
That's interesting, I only have the beta version of intel oneAPI installed,
Version 2021.1 Beta Build 20200827
but this rejects your code with an error when using the -stand flag,
as does ifort v20.
I failed to install the official oneAPI release remotely, and haven't
been to the office this year. On Wednesday, I will, however, and
hopefully then I can test.
--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany
Harald Anlauf
Jan 18, 2021, 3:16:08 PM1/18/21
to
JRR schrieb am Montag, 18. Januar 2021 um 15:39:25 UTC+1:
Hi Jürgen,
> That's interesting, I only have the beta version of intel oneAPI installed,
> Version 2021.1 Beta Build 20200827
> but this rejects your code with an error when using the -stand flag,
> as does ifort v20.
That is good to know.
> I failed to install the official oneAPI release remotely, and haven't
> been to the office this year. Onrticul Wednesday, I will, however, and
% ifort pr98686.f90 -stand -diag-error=8586,8125
That does the job for me.
Cheers,
Harald
Hi Jürgen,
> That's interesting, I only have the beta version of intel oneAPI installed,
> Version 2021.1 Beta Build 20200827
> but this rejects your code with an error when using the -stand flag,
> as does ifort v20.
> I failed to install the official oneAPI release remotely, and haven't
> hopefully then I can test.
As a possible workaround, one could turn these particular warnings into errors:
% ifort pr98686.f90 -stand -diag-error=8586,8125
That does the job for me.
Cheers,
Harald
gah4
Jan 18, 2021, 3:18:55 PM1/18/21
to
On Sunday, January 17, 2021 at 1:53:12 PM UTC-8, Harald Anlauf wrote:
(snip)
> Thus only a warning is issued, not an error, and the result changes!
Unless the standard specifically disallows it, non-standard extensions
are allowed. It is even allowed to do what you thought you wanted to do,
when you wrote something else.
It is, at least, nicely telling you that your code is non-standard, but also nicely
letting it go, anyway.
When it took hours or days to get the results back from a run, it was nice
of compilers to try to fix mistakes, at least enough to compile. That isn't
needed so much now, though.
(snip)
> Thus only a warning is issued, not an error, and the result changes!
are allowed. It is even allowed to do what you thought you wanted to do,
when you wrote something else.
It is, at least, nicely telling you that your code is non-standard, but also nicely
letting it go, anyway.
When it took hours or days to get the results back from a run, it was nice
of compilers to try to fix mistakes, at least enough to compile. That isn't
needed so much now, though.
Harald Anlauf
Jan 18, 2021, 5:22:08 PM1/18/21
to
gah4 schrieb am Montag, 18. Januar 2021 um 21:18:55 UTC+1:
> It is, at least, nicely telling you that your code is non-standard, but also nicely
> letting it go, anyway.
Depends on what you mean by "nicely". Add a
> It is, at least, nicely telling you that your code is non-standard, but also nicely
> letting it go, anyway.
print *, "x, m, q=", x, m, q
and you get:
&NML
X = 1.000000 ,
M = 1073741824,
Q = 4.2038954E-45
/
Not my understanding of "nice".
Robin Vowels
Jan 18, 2021, 9:43:53 PM1/18/21
to
On Tuesday, January 19, 2021 at 7:18:55 AM UTC+11, gah4 wrote:
> On Sunday, January 17, 2021 at 1:53:12 PM UTC-8, Harald Anlauf wrote:
>
> (snip)
> > Thus only a warning is issued, not an error, and the result changes!
.
> On Sunday, January 17, 2021 at 1:53:12 PM UTC-8, Harald Anlauf wrote:
>
> (snip)
> > Thus only a warning is issued, not an error, and the result changes!
> Unless the standard specifically disallows it, non-standard extensions
> are allowed.
.
> are allowed.
This is not an "extension". It is plain and simple a compiler error,
and completely wrong results are produced.
.
> It is even allowed to do what you thought you wanted to do,
> when you wrote something else.
.
> It is even allowed to do what you thought you wanted to do,
> when you wrote something else.
Nonsense.
.
> It is, at least, nicely telling you that your code is non-standard, but also nicely
> letting it go, anyway.
>
> When it took hours or days to get the results back from a run, it was nice
> of compilers to try to fix mistakes, at least enough to compile. That isn't
> needed so much now, though.
.
> It is, at least, nicely telling you that your code is non-standard, but also nicely
> letting it go, anyway.
>
> When it took hours or days to get the results back from a run, it was nice
> of compilers to try to fix mistakes, at least enough to compile. That isn't
> needed so much now, though.
Correcting compilers told you what the error was, and what it was doing
with it.
Compilers still need to diagnose errors, at the very least.
FortranFan
Jan 18, 2021, 10:35:41 PM1/18/21
to
On Monday, January 18, 2021 at 5:22:08 PM UTC-5, Harald Anlauf wrote:
> ..
From what you have posted on this thread, you should use IFORT compiler option -warn stderrors when using Intel Fortran compiler.
And any pending issues you encounter with Intel Fortran, post them at the Intel Fortran Community site:
https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler
> ..
> Not my understanding of "nice".
@Harald Anlauf,
From what you have posted on this thread, you should use IFORT compiler option -warn stderrors when using Intel Fortran compiler.
And any pending issues you encounter with Intel Fortran, post them at the Intel Fortran Community site:
https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler
Themos Tsikas
Jan 19, 2021, 8:59:07 AM1/19/21
to
On Tuesday, 19 January 2021 at 02:43:53 UTC, Robin Vowels wrote:
> This is not an "extension". It is plain and simple a compiler error,
> and completely wrong results are produced.
What we all agree is that this is a user error, the code is not standard conforming. Standard conforming compilers are required to report this condition. Extensions were introduced precisely for these cases, when a program unit has no interpretation within the standard. It may not be a sensible or useful extension but, in my view, it qualifies as an extension nonetheless. The compiler marks it with a message and the user can choose whether to treat it as a warning or an error. The results are not "wrong" as such because there are no "correct" results that should be returned, in Wolfgang Pauli's words "it's not even wrong". Can we reasonably ask for more?
> This is not an "extension". It is plain and simple a compiler error,
> and completely wrong results are produced.
Themos Tsikas, NAG Ltd.
Message has been deleted
Message has been deleted
Ron Shepard
Jan 19, 2021, 11:32:00 AM1/19/21
to
I long ago, even before it was a standard feature, got into the habit of
declaring namelist after all other declarations and right before the
executable statements. So long ago I had forgotten why. I guess this was it.
$.02 -Ron Shepard
Harald Anlauf
Jan 19, 2021, 2:31:57 PM1/19/21
to
FortranFan schrieb am Dienstag, 19. Januar 2021 um 04:35:41 UTC+1:
> And any pending issues you encounter with Intel Fortran, post them at the Intel Fortran Community site:
> https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler
I have been reporting issues with Intel Fortran for many years, but am now unable to use my account at this site. It seems to have been locked, and so far attempts to reactivate it failed. (No reaction or reply from Intel.)
> And any pending issues you encounter with Intel Fortran, post them at the Intel Fortran Community site:
> https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler
0 new messages