Settings to trap uninitialized variable

[Le_Callet__Morgan_M]

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 16.0.3.207 [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 ?

Many thanks

[Steven_L_Intel1]

Some examples of what's not working for you would be helpful.

/init:snan /init:arrays

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.

[Le_Callet__Morgan_M]

Dear Steve yes correct, i have uploaded 2 vs 2010 porject with and without snan the option. With the snan and initarray i dont get any message in debug.

I am using  Intel(R) Visual Fortran Compiler 16.0.3.207 [Intel(R) 64] 

Many thanks

[Steven_L_Intel1]

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.

[Le_Callet__Morgan_M]

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?

[Steven_L_Intel1]

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

[Steven_L_Intel1]

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 17.0.1.143 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

[Le_Callet__Morgan_M]

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

[Kevin_D_Intel]

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.

[Le_Callet__Morgan_M]

Dear Kevin many thanks.

Shall just not use Qinit until i have clear guidelines about 16.0?

Best regards

[andrew_4619]

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. 

[Kevin_D_Intel]

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