A simple question

[jscott]

Having used FORTRAN for many years and IFORT for several, I am trying to verify a program.

As part of that, I wanted to check that variables are not used until assigned. However, the program

X=Y/Z

STOP

END

is accepted by IFORT without warnings.

I would have expected warnings that Y and Z are not assigned, but no. Is there some way of making IFORT issue warnings in such cases?

[DavidWhite]

/check:uninint -- this is under the Run-time switches

[jscott]

Thanks David, but I was looking for a compile-time check.

As a run-time check, /check:uninit seems only to work for real variables which are not arrays. I am currently using  /Qinit:snan,arrays for real-time checking, but it does not handle integers. Since there is no equivalent of NaN for integers, I can't see how run-time checking can be done in that case.

If you have further ideas, I am all ears.

[jimdempseyatthecove]

Back in the early 1990's, Borland Turbo C/C++ would initialize references, including integers, that are yet to be initialized, to a page that was accessed inhibited. Upon first write, a page fault would occur, and the reference would be replaced with the intended address in a R/W accessible page, and the instruction re-issued. Should a Read occur first, then, this would cause a break into the debugger.

This could be used by Intel, but there may be other issues (e.g. execute-only pages).

Jim Dempsey

[jscott]

Yes. That would be a nice, clean way of doing it. Including integers and separating NaN's resulting from non-assignment from those coming from floating point operations.

I find your defense of Intel a bit weak. Why do execute-only pages exclude such data-faulting ones?

Seems to me this is just lack of effort on Intel's part.

[JFScott]

Just to note this does not address my original point of compile-time checking.

If IFX had compile-time and run-time checking of use of all unassigned variables with switches for integer/real, scalar/array (i.e. 4 choices in all), I would be there immediately.

[Steve_Lionel]

Enabling grouch mode here - back in the DEC days, both the older VAX FORTRAN compiler and the later GEM-based compilers could give you compile-time warnings when it could be proven there was a reference to an uninitialized variable. The move to Intel's IL0 back-end removed that capability, and the IL0 developers had no interest in implementing it. Worse, each Intel compiler that wanted to do run-time uninit checking was forced to roll their own. (We also lost GEM's excellent integer overflow checking, which never got added back.)

Now that LLVM is behind everything, it seems possible that there is a path to reinstating a valuable diagnostic, but there may not be interest in doing so. Allegedly, LLVM enables a better, common run-time check, but the evidence I have seen is that it is immature and perhaps limited to Linux at this point (at least it was initially - I don't know if that's still the case.)

I am a firm believer in giving diagnostics as early in the development process as possible, but I'm no longer in that game.

[jscott]

Thanks Steve. I should first say that you are a bit of a hero of mine, so many times your posts have saved me. You are always spot on and to the point.

Disappointed that there seems to be no way to do what I wanted, but never mind. I still like the Intel compiler.

I agree with all your remarks. I too started out with DEC and am now retired, though still active (mainly in the area of high-end scientific computing with large numbers of processors in parallel). Good to find you still around to help.

I have yet to make the transition to IFX. Why change when the old version is sufficient?

[JohnNichols]

In Visual Studio, changing to IFX is trivial and once you go to 2025 unless you are keeping the old, it is good idea. 

Sooner or later you will be in a corner you have to do it, speaking from experience.  

IFX has some minor quirks as has been discussed in this esteemed forum. 

Steve is more than a hero, he is one of the Gods of computing.  

[jscott]

Thanks for your viewpoint. I will no doubt switch to IFX before long.

Steve deserves your accolade.

[JohnNichols]

I will no doubt switch to IFX before long.

LOL, Like me you will make a mistake and no longer be able to use IFORT on a computer, as I look after quite a few computers, all around the world it is an easy mistake and it leaves you saying, Dang nab it Bruce or similar thoughts.  Actually it is quite ok. 

I am being annoying here, spare time fault, because I had to replace a computer in the Smithsonian Institution as the old one, (a new one that was a week old failed in spectacular fashion) lost vision.  You cannot fix a computer if you cannot see the output. I am not complaining, it was a new INTEL NUC and so I sent an old INTEL NUC as a replacement, with VS 2022 Preview and VS 2022 all coded for one api.  The SI curator had to pass through a 9 inch vertical space to put in the old new computer and now it runs, but I await update on VS so I can start Fortranning.  (Is that a word, Jim will know.) 

PS This forum provides social comfort for programmers that is an important part of your mental health and it is cheaper than a visit to a shrink, like my father.

[jscott]

Thanks for your reply, which had me laughing.

But, for me, the switch to IFX is not as much of a no-brainer as you suggest. I am a university researcher and, as I said to Steve, use clusters with a large number of processors in parallel (fluid mechanics).

For that, I first debug on a local machine with less processors. At that level, I can control which version of the compiler is used, but not once it gets handed over to a cluster. It is therefore helpful if the versions coincide, more or less. Since the main cluster I use is still on version IFORT 2022, the switch to IFX on the local machine is not obvious and requires more motivation than I can currently see.

I suspect that many users of IFORT are in a similar position.