Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
26855 Discussions

"Variable used before set" warning

belmont
Novice
554 Views

Hi,

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.

0 Kudos
12 Replies
FortranFan
Honored Contributor II
548 Views

@belmont ,

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.

 

mecej4
Black Belt
548 Views

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.

JohnNichols
Valued Contributor II
536 Views

-858993460

The program executes because the variable is assigned a number, I am sure this number has some meaning in binary terms which is

-0b110011001100110011001100110100

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.  

Capture.PNG

JohnNichols
Valued Contributor II
534 Views

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

20070305sunny_bank.jpg

 

 

Steve_Lionel
Black Belt Retired Employee
530 Views

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.

JohnNichols
Valued Contributor II
492 Views

Capture.PNGNo running it on different days and adding variable I always get the same number the one I quoted, the computer has been rebooted and the program recompiled 

YOu might care to run it to see, maybe it is machine dependent

Steve_Lionel
Black Belt Retired Employee
490 Views

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
JohnNichols
Valued Contributor II
462 Views

https://software.intel.com/articles/detection-of-uninitialized-floating-point-variables-in-intel-for...

In your case, what switches did you set? 

Is there a difference between int and real in the switches

andrew_4619
Honored Contributor I
464 Views

@john I think \qsave and \qinit compiler options influence things as well as debug/release 

LRaim
New Contributor I
504 Views

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

Regards  

andrew_4619
Honored Contributor I
498 Views

"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. 

belmont
Novice
401 Views

I would like to thank everyone that replied in tis topic. I have asserted and checked almost everything reported and I think I know the best way to proceed. Thanks again!

Reply