uninitialized variables not caught when passed to procedure

[vivekrao4]

For the program

module twice_mod
contains
function twice(x) result(y)
real, intent(in) :: x
real :: y
y = 2*x
end function twice
end module twice_mod

program xabc
! test what compiler does with an uninitialized variable
use twice_mod, only: twice
implicit none
real :: x
if (.true.) print*,twice(x)
print*,"x=",x
end program xabc

Intel Visual Fortran Version 9.1 Build 20070109Z Package ID: W_FC_C_9.1.034 gives

1.0689561E+37
x= 5.3447806E+36

but when .true. is changed to .false. above, the uninitialized value of x is caught. It appears that passing a variable to a procedure sets its value to some random number if it was previously uninitialized. It would be nice if using uninitialized variables within procedures were caught.

IVF also says nothing about

subroutine foo(x)
real, intent(out) :: x
x = 2*x
end subroutine foo

program xfoo
real :: x
x = 1.2
call foo(x)
print*,"x =",x
end program xfoo

giving output

x = 2.400000

The intent(out) attribute should have the effect of making the argument uninitialized.

Vivek Rao

[Steven_L_Intel1]

The compiler's current uninitialized variable checking is not thorough and tends to be optimistic. In the next version, we'll have a new feature that can optionally provide whole-program static analysis for errors such as these. When I enable that in a test compiler for the furst case, I get:

t2.f90(15): error #12143: [SV] "X" is uninitialized

and for the second case I get:

t3.f90(3): error #12014: [SV] argument "X" is INTENT(OUT) dummy argument, but it is used before set

[chuckhp]

Do you have any idea when the next version having this feature (compile time checking of uninitialized variables) will be released? We are in desperate need of this capability since we are currently in the process of converting a HUGE project over from CVF to IVF, and we have found that uninitialized variables are causing all sorts of problems in IVF even though in CVF they were always (properly, imho) initialized to zero. After realizing there was no option to automatically initialize all automatic variables to zero, we resigned ourselves to manually fixing all of our initialization problems.

Unfortunately, I was then very discouraged to find that there is no simple way of doing that in IVF. We literally have thousands of files that we need to go through, so finding all of them manually would be a nightmare. We tried using the run-time option to catch uninitialized variables, but it was complaining about 'undefined' variables, not just uninitialized variables, which is not the same thing. Plus, even if this worked properly, it would be extremely tedious because we would have to compile the entire codebase, run it and wait for it to crash on the first occurance of an uninitialized variable, then fix and repeat so it can find the next one, one at a time. We would have to repeat this process hundreds (or perhaps thousands) of times to catch all of them. This is a huge codebase for doing engineering calculations that has been continuously developed for over thirty years and has worked fine on numerous previous compilers (Micrososft Powerstation, CVF) and up until now, variable initialization has never been an issue. I know you have mentioned in a previous post that CVF never initialized variables to zero, but in the thousands of files we have in our project, and the multiple compilers it has been ported from, this is the first time that our variables have been initialized with anything other than zero values.

At the moment, my only method of finding uninitialized variables is by running CVF and IVF side by side (in different VMWARE instances running simultaneously) to use the compile-time option in CVF to help find the uninitialized variables in the old codebase and then make the required changes in the IVF codebase. This is very tedious, but I see no other way until this feature becomes available in IVF, hence my inquiry into the next release date you mentioned.

Is it possible to get a copy of the test compiler you used above to do exactly what we need to do? We're in a bit of a pinch to get this done as soon as possible to keep on our development schedule.

[Steven_L_Intel1]

The feature I described above is part of the 10.0 product and is called "Static Verifier". It doesn't work quite the same way as it does in CVF in that you can't just add a switch to your regular build. To use Static Verifier, you need to create a separate build configuration as it will not produce an executable file. This is described in the compiler documentation.

The run-time option uses the word "undefined" to be what you call uninitialized.

I suggest that you compile with the option /Qsave (Data > Local Variable Storage > All variables SAVE) This will get you closer to what CVF did.

[Intel_C_Intel]

You may also wish to compile your files with g95 using the option -Wunset-vars that will show you the variables that are not set; then you can correct that and continue with your project in Intel Visual Fortran. When I compiled your example with that option I got:

In file ZA.FOR:16

REAL*8 X
1
Error (113): Variable 'x' at (1) is used but not set

take care

Michael

[yair999]

I have created a separate build configuration for the static verifier.

I then used the /Qdiag-enable-sv3 in the properties'Fortran command line section. Itried it on the following sample but did not see any warnings during the build phase:

x=x+1

end

Anything I have missed?

Thank you,

Yair

[Steven_L_Intel1]

You have the spelling wrong. It should be:

/Qdiag-enable:sv3

Colon instead of dash before sv3. When I do it I get:

C:Documents and SettingsSteve>ifort /Qdiag-enable:sv3 t.f90
Intel Visual Fortran Compiler for applications running on IA-32, Version 10.0
Build 20070426 Package ID: W_FC_P_10.0.025
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.

C:Documents and SettingsSteve .f90(1): error #12143: [SV] "X" is uninitialized
C:Documents and SettingsSteve .f90(1): warning #12136: [SV] program has no output into external files

This last is noting that the program has no effect.

[yair999]

You're right, my bad.

I now works from the command line, however still not from the VS2005 IDE.

How should I specify the special configuration apart from the /Qdiag-enable:sv3 option?

Thank you,

Yair

[Steven_L_Intel1]

Using Static Verifier in the Microsoft Visual Studio Environment

When Static Verifier support is enabled within the IDE, the customary final build target (e.g. an executable image) is not created. As such, we recommend that a separate "Static Verification" configuration be created, by cloning the existing Debug (development) configuration, for use when static verification is desired.

• Select the Project Configuration Manager via the Build menu or from the Project Properties window.
  • In the "Active Solution Configuration" dropdown, select
  • Provide a name for this configuration.
  • Specify to "Copy Settings from" the Debug configuration.
  • Exit out of the Configuration Manager.
• With the new configuration active, navigate to the Intel Fortran > Diagnostics property page. Use the "Level of Static Analysis" and "Analyze Included Files" properties to control Static Verification.

[yair999]

Well, that worked.

However, if I use /Qdiag-enable:sv3 /Qdiag-enable:sv-include in the Intel Fortran> Command Line property page instead of the Diagnostics property page, I get the following:

------ Build started: Project: kuku1, Configuration: Static_Vrifier Win32 ------
Compiling with Intel Fortran Compiler 10.0.027 [IA-32]...
kuku1.f90
Compiling manifest to resources...
Linking...
ipo: remark #11001: performing single-file optimizations
ipo: remark #11005: generating object file ipo_18446obj.obj
Embedding manifest...

Build log written to "file://C:Documents and SettingsyairMy DocumentsVisual Studio 2005Projects estskuku1Static_VerifierBuildLog.htm"
kuku1 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Should it not work the same way?

Yair

[Steven_L_Intel1]

It looks as if you enabled /Qipo - that conflicts with Static Verifier.

[yair999]

Here is what is listed under "All Options:" on the Fortran>Command Line property page:

nologo /Zi /Od /gen-interfaces /warn:interfaces /module:"Static_Verifier" /object:"Static_Verifier" /traceback /check:bounds /libs:static /threads /dbglibs /c

I do not see /Qipo here.

Any idea where /Qipo could have come from?

Thanks,

Yair

[Steven_L_Intel1]

Very curious. But I don't see /Qdiag-enable there either. Are you looking at the right configuration?

[yair999]

You don't see it because it isunder "Additional Options:" at the bottom ofthe Fortran>Command Line property page.

I could attach the relevant screen pictures but I don't see how to attach a file here.

???

Yair

[Steven_L_Intel1]

You can attach a file by clicking on the Options tab while composing a message. Better would be the output from the Build window. You should not need to use the Additional Options to speicfy Static Verifier.

[yair999]

OK, I've attached two pics in a doc file.

I know I do not need to use the Additional Options, but I ususally prefer to see all my changes to the default options in one place.

Yair

[Steven_L_Intel1]

If you put in Additional Options things which can be specified in the property pages, you end up confusing things. In this case, you get the incorrect results. Please use the property page entries instead which works.

[yair999]

Hmmm...

I apologize for confusing the compiler :). I do not think this should happen and it seems to me to be a bug, but I accept it as a fact.

Thank you,

Yair

[Steven_L_Intel1]

It's not the compiler you're confusing, but the Visual Studio integration, which needs to do different things if you have enabled Static Verifier. I agree that the behavior seems odd so I will report it. But in general I recommend that you use Additonal Options only for those options not available through the property pages.