I would like to know if there is some online help or useful thread/topic where i could get info about which options to set to get the compiler to break with the message variable has been used without being initialized.
I am now using Intel(R) Visual Fortran Compiler 18.104.22.168 [Intel(R) 64] and have the feeling that it does not trap as much as in Intel(R) Visual Fortran Compiler XE for IA-32, version 14.0.1 Package ID: w_fcompxe_2013_sp1.1.139.
With 14.0.1 sp 1 1.139 i a messge was also issued in release and debug now it seem it goes over silently.
If stack data are set to SNAN will the trapping be better ?
Some examples of what's not working for you would be helpful.
will catch a lot of floating point uninitialized references. I think /init:arrays is new in 17.0. /check:uninit will catch a subset of some local variable issues.
Interesting. Your original program never uses v1 so it's not terribly surprising that nothing gets detected. But when I add a use of it, something goes wrong. I'll let the developers know.
Thanks Steve, I was expecting a run time error when assigning v2 to v1 and one is fired without the snan but isn't when using snan.
Out of interest what does Initialize Stack variables to an unusual value do?
/init:snan depends on the processor raising an exception on a floating point load or arithmetic operation. A simple assignment might not be done with FP instructions so you might not get an error there. It usually does work in real programs, but when I modified your program to use the value, it did raise an exception (good) but then got an access violation trying to report it (not good.)
"Initialize Stack variables to an unusual value" does nothing useful - don't use it, especially in conjunction with /init.
For some reason I can't reproduce the "something else goes wrong" bit. /Qinit:snan does what it is supposed to.
program Console16 implicit none ! Variables real(4) ::v1,v2 ! Body of Console16 print *, 'Hello World' v1 = v2 + 3 print *, "After assignment" print *, v1 end program Console16
C:\Projects\U703725>ifort /Qinit:snan /traceback U703725.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 22.214.171.124 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:U703725.exe -subsystem:console -incremental:no U703725.obj C:\Projects\U703725>U703725.exe Hello World forrtl: error (182): floating invalid - possible uninitialized real/complex vari able. Image PC Routine Line Source U703725.exe 000000013FE910C5 MAIN__ 11 U703725.f90 U703725.exe 000000013FEDCEDE Unknown Unknown Unknown U703725.exe 000000013FEDD275 Unknown Unknown Unknown kernel32.dll 00000000773859CD Unknown Unknown Unknown ntdll.dll 00000000775BA561 Unknown Unknown Unknown
Dear Steve, I am a bit confused here: what do you mean by the something else go wrong.
With your program and /Qinit:snan i do get an access violation, without /Qinit:snan i get the "the variable is being used without being initlialized'.
Would you recommend not to use /Qinit in my case and my version of the compiler ?
Would you also recommend that i don't use /Qinit: array
What About /Qinit: zero ?
Thanks and regards
Steve is away so he can’t follow up at the moment. I don’t have details about what he experienced when he wrote “something else goes wrong”; however, in his post #7 he noted not being able to reproduce that so I don’t believe there’s anything to be concerned with further regarding this comment.
Use of the /Qinit options you note should be fine with your compiler, including /Qinit:arrays and /Qinit:zero.
There may be follow-up remaining for us with the access violation but as I understand Steve’s comment in post #6 it still raises the exception thus should be helpful with finding uninitialized variables. It is unclear whether his comment related to the 17.0.1 compiler shown in post #7 or the 16.0 compiler you noted using. We’ll follow-up with him on that.
To be honest all variables should be properly initialised in code and not rely on compiler initialisation. In any code where there is active development that should be the goal. The Qinit stuff is just a kludgey fix for old non-conforming code.
@Morgan M - It should be fine using /Qinit:snan with 16.0. As Steve notes in post #6, it works in real programs and even your example in terms of raising the exception; thus, it should be helpful in locating variables for which explicit initialization should be added. If you happen across both the exception being raised and the access violation he mentions, the exception would still be helpful in guiding which variable to add explicit initialization for as per your interests.