uninitialized variables

uninitialized variables

is there a way to detect uninitialized variables at compile time rather than at run time?

is there a way to force uninitialized variables to zero (i know this is not good programming but ....)

thanks, james

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Steve Lionel (Intel)'s picture

You can try the Static Verifier feature - but it may show lots of false positives. Read the documentation for more info - it isn't quite as simple as throwing a switch.

You can add /Qsave /Qzero which will set static variables to zero. I don't recommend this.

Steve

Quoting - jfdoyle
is there a way to detect uninitialized variables at compile time rather than at run time?

is there a way to force uninitialized variables to zero (i know this is not good programming but ....)

thanks, james

(1) compiling time detection -- you may try to use Static Verification, although, I don't have any positive experience with it (and a targeted for fixing support issue). Maybe there is other technique which I'm not aware of.

(2) Initializing to zero - add options /Qsave and /Qzero
(Project->Properties->Fortran->Data->Initialize Local Scalar Variables
Project->Properties->Fortran->Data->Local Variable Storage (ans set "Save ALL")

A.

Sorry Steve, I posted at exactly the same time. Then, trying to edit it, I received this:

DB ERROR: Cannot add or update a child row: a foreign key constraint fails (`redfort/rf_topic_reply`, CONSTRAINT `rf_topic_reply_ibfk_4` FOREIGN KEY (`reply_private_user_id`) REFERENCES `rf_user` (`user_id`)) / update rf_topic_reply set reply_text='
', reply_title='Re: uninitialized variables', modified_by_id=342379, modified_dt=now() ,rec_status='ACTIVE',reply_is_paid_customer = 'NO',reply_is_private='NO',reply_private_user_id='.NULL.' where reply_id=76490
sql error

A.

Quoting - jfdoyle
is there a way to detect uninitialized variables at compile time rather than at run time?

is there a way to force uninitialized variables to zero (i know this is not good programming but ....)

thanks, james

One can use Intel Static Verifier(ISV) if you using Intel C++ Compiler (ICC), also compile your code using -Wall.

Else one can also try some other static-analysis open-source tools like - Splint andmyGCC if you are using GNU compilers, but here also one can compile the code using -Wall.

Note: Documentation for static-analysis using Intel Static Verifier (ISV) is very limited, only in 13-15 pages in covers the basic things, personally I am not satisfied with ISV documentation in exploring the depth for static-analysis. I am not sure when one can have somewhat application oriented documentation for ISV from Intel.

~BR

I believe -Wall does include -Wuninitialized in gfortran, not that we can expect many Windows users of ifort to switch over to gfortran for diagnosis. It's active only when -O is set. I wouldn't suggest the outdated gfortran or g77 still included in many installations. Older gcc would have required the uninitialized option to be set specifically, but we're talking about Fortran here. ifort has static verifier.
ifort -check includes the uninit option by default. For OpenMP or parallel code, it may be better to use Thread Checker, but that is run-time analysis.

Steve Lionel (Intel)'s picture

Quoting - ArturGuzik

Sorry Steve, I posted at exactly the same time. Then, trying to edit it, I received this:

DB ERROR: Cannot add or update a child row: a foreign key constraint fails (`redfort/rf_topic_reply`, CONSTRAINT `rf_topic_reply_ibfk_4` FOREIGN KEY (`reply_private_user_id`) REFERENCES `rf_user` (`user_id`)) / update rf_topic_reply set reply_text='
', reply_title='Re: uninitialized variables', modified_by_id=342379, modified_dt=now() ,rec_status='ACTIVE',reply_is_paid_customer = 'NO',reply_is_private='NO',reply_private_user_id='.NULL.' where reply_id=76490
sql error

A.

This should be fixed now.

Steve
Paul Curtis's picture

Quoting - Steve Lionel (Intel)
You can add /Qsave /Qzero which will set static variables to zero. I don't recommend this.

Why not?

This was the default behavior of CVF and many (all?) earlier Fortran compilers, and IVF versions of previously working projects generally don't work at all unless these (Qsave, at least) are set. I never rely on implicit compiler behavior, always initialize all variables explicitly, but Qzero sure seems like a good place to start.

Steve Lionel (Intel)'s picture

/Qsave was indeed the CVF default, which is why, at least as of IVF 11, it is applied when you convert a CVF project. CVF had no concept such as /Qzero and did not initialize variables to anything by default. But because SAVE semantics was the default, many people mistakenly believed that zero-initialization was there too. It wasn't.

/Qzero is a crutch for incorrect code. It basically says "I can't be bothered to write legal Fortran so I want the compiler to paper it over for me." If you need this, then my advice is to fix your code. But /Qzero is there if you want to put up with hassles and errors down the road should you use a compiler that does not support /Qzero or a similar option. In fact, I have a distaste for ANY use of compiler options that change the meaning of the source. If you want variables initialized, put it in the code.

/Qsave is there because, as you say, CVF and many older compilers implied SAVE semantics for local variables. Here again, the correct approach is to add SAVE declarations where they are needed.

Options you should not use include /Qsave, /Qzero, /names, /iface, /real_size, /integer_size, /recursive. There are probably others that don't come directly to mind. All of these concepts can and should be expressed in the source.

Steve

Login to leave a comment.