See the following trivial program
program test implicit none integer i,j,k i=1 k=i+j end
Compiling this program with Fortran 77 gives the warning "Variable used before set". However compiling with ifort does not reproduce the warning.
Can I tell the compiler of ifort to show this warning? It would be useful since I recently moved to ifort and do mathematics and this could be useful to check issues on bigger programs.
Please note that I use Visual Studio 2019.
To the best of my knowledge, Intel Fortran compiler does not have a compile-time option to raise attention to the issue you mention. However Intel Fortran does offer a run-time option with /check:uninit (on Windows): see this.
Your work process can possibly be to turn on such checks during development and debug phase of your program writing and once you have validated your code via various unit tests and full runs to a desired level of acceptance, you can move to a "release" mode where you don't employ such checks because they can impact performance.
Another option with a language such as Fortran with an international standard and many different compilers - both commercial and open-source such as gfortran - is to try your code with various compilers and strive toward standard-conforming code that works with more than compiler.
Compilers vary regarding their ability to catch user errors. Some compilers can detect errors at compile time, others at run time, still others may never do so.
With Intel Fortran, try the /check option.
The program executes because the variable is assigned a number, I am sure this number has some meaning in binary terms which is
No idea why this is the number assigned - but it adds and subtracts nicely.
But in VS you can set all variables on creation to NAN or zero - see below.
Remember Fortran grew from card readers and very old compilers and a lot of the old geezers or is that goosers not sure, are used to this sort of stuff and the standard changes quickly.
If you want a language that changes rapidly and picks these errors try C#, but you will find it is twice as slow but it does have one or two features that would be nice in Fortran -- read csv files easily and streams but it is slow - of course there is a single advantage it is quite easy to translate C# to Fortran and back.
mecej4 taught me that - even though that was not his intent. I am pretty sure this has a Froude number greater than 1 - but what fun to sit in the backyard with a beer and watch the water pass
This morning in UK in Lake District and some of the first Fortran code I wrote was to model this stuff back in the days before Star Wars
The variable j is not "assigned" - you get whatever happened to be in that location (probably on the stack) when the program starts.
The DEC/Compaq compilers had compile-time diagnosis of uninitialized variables, but this was lost when the switch to the Intel "back end" was made, as this detection requires knowledge of control flow and only the back end knew that. The Fortran team added the run-time detection that does the best it can, but it can't catch all cases.
In a Release configuration, the entire program is evaporated because there is no output. In a debug configuration, you get whatever the value of the EAX register was, plus 1. As it happens, this register is used in the main program's prologue code so that's why you always get the same value. You certainly can't depend on that in general, though.
If I enable uninitialized variable checking, I get:
forrtl: severe (194): Run-Time Check Failure. The variable \'_TEST$J\' is being used in \'D:\Projects\Console16\Console16.f90(5,1)\' without being defined
In your case, what switches did you set?
Is there a difference between int and real in the switches
Some month ago I raised the same problem on the Intel support providing the output of the Lahey compiler which issued the warning.
It seems that Intel has added this request to their 'to do' list of the Fortran compiler
"It seems that Intel has added this request to their 'to do' list of the Fortran compiler" where do is at some point before the end of time..... I can't see it as a top priority you catch most of those run with check all debug setting. Nice to have, but, in many cases not possible to check anyway.