@wspector if you use Conda, just “conda install” it. It’s alpha quality, meaning it is expected to break on your codes. With that in mind, you might be surprised about all the things that already work, and please report all bugs. We are working hard on modern features, Hollerith is planned after we reach beta.
1 Like
I can live with @certik’s camp 2 if compilers warn but allow compilation of programs with obsolescent or not-recommended features. And options to not issue warnings, or turn them into errors preventing compilation, are also OK.
1 Like
Indeed. We maintain a very large industrial software, and for a given released version there are fixed OS version, compiler versions (that can be old, we still support versions that require Intel 18 and gcc 6) and compiler options. The slightest change in the options can potentially trigger hundreds orange or red lights in the test suite, that have to investigated. That’s what happens when a new release is build with a new OS version and new compiler version, and the validation process takes more than one year.
Anyway, whether the compiler should warn by default or not is a detail: clients who do NOT want to be warned by default about this or that do turn off the warnings anyway, and yes they DO know that they have obsolete stuff in their codes, they just decide to live with it. And no, this is not necessarily “penn-wise etc”: for instance we have some old features in our software that are almost no longer used, but “almost no longer” is not “no longer at all”, so we keep them anyway. But obviously any evolutive maintenance in these parts of the code would cost much more than it would worth.
3 Likes
From the perspective of compiler support, with which I am intimately familiar, customers finding that their existing code starts generating diagnostics when they update versions leads to a deluge of complaints to the support team. In an ideal world, yes, compilers should by default inform users of nonstandard, obsolescent, or deleted features, but that just annoys commercial customers and leads to perceived quality problems with the compiler.
There’s a LOT of “legacy” code out there, and the users of such code don’t want to start chasing what they consider “error messages”. That said, I am all in favor of compilers adding diagnostics for incorrect code - whether or not it “worked” in an earlier version.
1 Like
What we do is that for devs all warnings are turned on; when the code is released, we turn them off for the user. They would only see catastrophic errors!
1 Like
As a Fortran user who still holds on to some old extensions I see as beneficial, I have always considered Hollerith constants and storing Hollerith constants in integer or real arrays as one of the worst features in pre-F77 Fortran.
If you are going to maintain the code, my own rule was to eliminate these constants, and replace them with character strings and character arrays.
My experience is you are much more likely to introduce a regression when changing Hollerith constants, than when converting them to character strings. It is also much better to document character values as character variables, rather than storing them in integer or real arrays.
Eliminate this awful feature from your code.
2 Likes
Hi John,
I agree. It is in my list of things to do, I contribute to this codebase purely as a hobby so my work is slow 
And as someone on the end user side, when upgrading to a newer version (or different vendor) compiler I’ve always appreciated it finding issues in the codes I am working on that were previously hidden. Same with using tools like bounds checking and valgrind at runtime.
WRT Hollerith constants, I helped convert a lot of code to use character data type in the 1980s and early '90s. From about Y2K onwards, it has seemed like any well-maintained code has moved away from them. In some cases, the applications were re-written in C/C++ and the old Fortran versions were abandoned.
Picking up old code from places like netlib, that have not been updated since like the 1980s, are an exception.
1 Like
As a end user of ifort, I always use -warn -check when compiling in debug mode, which finds out most -if not all- of the deprecated/deleted features of the standard. Specific warnings can be disabled (possibly file by file depending on the build system).
1 Like
You might want to add -stand and -standard-semantics for better results.
Although the -standard-semantics flag is a “coloring” one —i.e., once some object file is created with that flag, everything else consuming that object file must also include the flag.
1 Like
As I have remarked earlier, -standard-semantics does not affect diagnostics. Rather, it changes default run-time behaviors (semantics) to match the current Fortran standard (whichever standard the compiler claims to support, unaffected by standards-checking options.) Yes, if you use this option you really should use it for your whole build, but it is not relevant to this thread.
I get that -standard-semantics sets several -assume flags, and therefore has an effect on the runtime. But it also seems to affect the -stand itself (or it completes it).
For example, the following code throws an error with -stand alone (even though -stand defaults to f18):
module mod1
implicit none
contains
pure function factorial(n) result(fact)
integer :: fact
integer, intent(in) :: n
if (n <= 1) then
fact = 1
return
endif
fact = factorial(n-1) * n
end function
end module mod1
$ ifort -c -stand -diag-disable=10448 recursive.f90 && echo "OK"
recursive.f90(14): error #6437: A subroutine or function is calling itself recursively. [FACTORIAL]
fact = factorial(n-1) * n
---------------^
compilation aborted for recursive.f90 (code 1)
$ ifort -c -stand -standard-semantics -diag-disable=10448 recursive.f90 && echo "OK"
OK
Yeah. That’s because Intel Fortran, by default, doesn’t make procedures recursive, a F2018 change. So, without -standard-semantics. you have a recursive call to a non-recursive procedure, which the compiler then complains about. It’s not changing the diagnostics, it’s changing the semantics (which in this case can lead to a diagnostic.)
For Intel, -stand does not affect semantics - it is a diagnostic option only. I know that some other compilers have options that say “pretend you’re Fortran 2008” or some such, but Intel does not.
Yes, so -stand and -standard-semantics are better used together.
And, off-topic: with ifx, Intel missed the opportunity of making -standard-semantics the default —and it’s not really about not annoying customers, since the new -check uninit behavior already did that 
.