Initialization of module variables

[abhimodak]

I believe that this topic has been discussed before. Can someone offer a suggestion/pointer?

In the test program below, the module variable J gets initialized to zero. Thus, it can not be trapped used /check:uninit or /Qtrapuv. Is there any way to achieve that? {Variable k can be "trapped" as expected.}


Abhi


----

[fortran]      Module OM
         Implicit None
         Integer :: J
      End Module OM
      
      Program Test_ModInit
         Use OM
         Implicit None
         Integer :: k
         print *, J  ! can not be trapped by /check:uninit or /Qtrapuv
         print *, k  ! gets trapped
      End Program Test_ModInit[/fortran]

[Steven_L_Intel1]

In the source you provide, J is uninitialized. The initial value is unpredictable. If you want it to have a value, use "Integer :: J = 0".

/check:uninit does not check module or COMMON variables. /Qtrapuv is completely useless and should be ignored.

[abhimodak]

Hi Steve

(1) I am expecting that J is uninitialized and unpredictable.
(2) I also understand (a) how to initialize j = somevalue.

Taking liberty to make a bold statement -- However, what I have been "consistently" seeing is that IVF makes it appear that all integer variables in the module are initialized to zero and one gets tricked!

So my question was is there something that I can do about trapping uninitialized module variables.

Sincerely
Abhi

[jimdempseyatthecove]

So my question was is there something that I can do about trapping uninitialized module variables.

Not without writing code to test for uninitialized modulevariables.
How much work are you willing to expend in order to catch these uninitialized modulevariables?

1) produce map file
2) read map to determine which linker segment name has modules (.data., .bss., ...?)
3) write assembler file to create large same named segment prefilled with unique data pattern
e.c. hex byte CA repeated (CACACACA......
end that assembly segment with a reorigin to beginning of named segment
I think this would be

$ = 0
4) modify linker command line to include the object file of the assembler first
5) add code to read the .MAP file or the Debug info walking through module data checking for CACA's
6) call this at PROGRAM


I looked in the LINK option list for an option to preload undefined data to a specific value. Did not see such an option (I think the old Borland Turbo Linker had such an option and thus would omit steps 1:4)

A potential hack might be to compileyour modules as seperate library with full debug and /RTCu
This may prefill the uninitialized data with a known pattern. But compile the rest of your aplication in Release mode without /RTCu. You will still need to add steps 5 and 6 to catch the uninitialized variables (in particular INTEGER, character and logicals. The REAL's might get preloaded with NaN's.

Jim Dempsey

[Steven_L_Intel1]

/RTCu is the same as /check:uninitialized. It does not fill data with anything but rather adds separate run-time code to check that routine scalar local variables are initialized. It does not look at module variables, COMMONs, dummy arguments, arrays or derived types.

You might try the "Source Checker" option. My experience is that this gives a lot of noise, but sometimes there is useful stuff in there. It isn't as simple as throwing a switch, so please read about it in the documentation.

[abhimodak]

Thanks Jim and Steve.

Steve, I know /Qdiag option. What is the syntax for source checker?

Abhi

Just one observation: Among the 4 to 5 compilers I have used so far, this kind of error is only trapped by FTN95's /checkmate switch.

[Steven_L_Intel1]

The syntax is /Qdiag-enable-sc:2 but if you add that you won't get an executable, just diagnostics. Please do read the documentation on Source Checker because it's a rather complex tool. In its current state, I find it to have too much "noise" for Fortran code, but it is being improved.

[abhimodak]

Hi Steve

I used Qdiag-enable:sc3 and I got the following:-

>Test_SeeModuleVariable.f90(44): warning #12301: "J" is set to zero value by default

(1) Thus, it does report it. Fortunately, in this case it did not create too much information.
(2) It confirms that IVF does initialize the integer module variables to 0.

Abhi

[Steven_L_Intel1]

I would not put too much faith in that second message. The compiler does not explicitly initialize such variables unless you also use /Qzero.

[abhimodak]

Hi Steve

Below is the build-log. I am not using /Qzero. Would it be ok to request to somewhat escalate this issue? i.e. As far as I have seen, the integer module variables are consistently appearing to be initialized to 0. I don't know about standard saying anything about that and hence I believe that compiler cannot be blamed for it. It is program's fault but the request is to get some mechanism of handling it.

Abhi

Build Log

Build started: Project: Test_SeeModuleVariable, Configuration: Debug|Win32

Output

Compiling with Intel Visual Fortran 11.1.065 [IA-32]... ifort /nologo /debug:full /Od /Qdiag-enable:sc3 /warn:interfaces /module:"Debug\" /object:"Debug\" /traceback /check:bounds /check:uninit /libs:static /threads /dbglibs /c /Qvc8 /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin" "C:\Abhi\MySource\Tests\Test_SeeModuleVariable\Test_SeeModuleVariable.f90" Performing source code analysis... Link /OUT:"Debug\Test_SeeModuleVariable.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Abhi\MySource\Tests\Test_SeeModuleVariable\Debug\Test_SeeModuleVariable.exe.intermediate.manifest" /DEBUG /PDB:"C:\Abhi\MySource\Tests\Test_SeeModuleVariable\Debug\Test_SeeModuleVariable.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Abhi\MySource\Tests\Test_SeeModuleVariable\Debug\Test_SeeModuleVariable.lib" /qdiag-enable:sc3 "Debug\Test_SeeModuleVariable.obj" Test_SeeModuleVariable.f90(10): warning #12301: "J" is set to zero value by default Test_SeeModuleVariable.f90(11): error #12143: "K" is uninitialized Test_SeeModuleVariable - 1 error(s), 1 warning(s)

[Steven_L_Intel1]

I will see if I can find out why Source Checker puts out that message. In most cases, the module variables will start as zero, because they are static and in an image section that usually starts out zeroed, but the compiler does not do anything explicit to enable that and it is possible that the variable will have some other value. Just because you see it as zero, that doesn't mean the compiler made it so.