/Qsave and Update 5

[andrew_4619]

I had an old program that I used to compile with /Qsave. Some months back I 'bit the bullet'  and removed this option and then had to deal with the resulting bugs in my code.

I recently changed from update 3 to update 5 (2013.5.198) and some more bugs in my code have come to light. I am assuming that in some cases previously save was default and now it isn't? Two questions arise:

1) Some insight into this phenomenon/change would be helpful as it might help to find other bugs

2) Is there any plan to improve the detection of uninitialised variables? Some insight into what it does and doesn't detect would be helpful.

[andrew_4619]

I should add I read the release notes and more specifically the compiler changes which is a long list of DPD referances. The Initital one line description of a DPD issue is often (nearly always!) not very meaningful out of context, It would be helpful when the fix is posted if a more meaningful paragraph or two could be added which some explaination of the chaneg/fix.I am sure tou must record this on some internal documents

[mecej4]

app4619 wrote:
 I am assuming that in some cases previously save was default and now it isn't?

As far as I know, from the earliest versions (Version 4, circa 2000, EPC/Intel) Intel Fortran has never made /Qsave the default. You could have make /Qsave the default by setting that option in the configuration file ifort.cfg at some time. If you subsequently installed a newer version of IFort into the same directory, the ifort.cfg file would be overwritten by an empty (except for comments) file, and /Qsave would no longer apply.

How may lines of code are involved, and how deeply are the subroutine calls nested? Is the code Fortran 77? Fortran 95 or later? Does it use default initialization of components of user-defined ("derived") types?

[TimP]

As you found, there was no foolproof way of using ifort to detect bugs associated with /Qsave.  It's possible that your code happened not to over-write a storage location and changing compiler version or your code has changed the behavior, as often happens with such bugs.  Looking for an intentional change in the compiler which exposes more bugs is likely to be unproductive.  Perhaps you might find something if you compared the output of /Qopt-report-file between the compiler versions.

Among the better papers on detection of undefined variables with ifort is the one by Dave Barker; unfortunately, it concentrates on linux.  http://www.nas.nasa.gov/hecc/assets/pdf/training/UnInit_Fix_your_code_2012_10_31.pdf ; but this is better than grasping at straws.

You could try another compiler or analyzer with options to detect undefined; even gfortran might find different cases.

[andrew_4619]

@mercej4: The two issues I found yesterday where a simple (default) integer and a real(8) in a sub-program. The correct function would only occur if they were initialised to zero. In the case of the integer the first reference was on a subroutine call so I think that is why it escapes the ifort checking, the case of the real(8) it was assigned to another variable in the same subroutine and it clearly needed to be initialised to zero have the save attrubute for subsequent calls to work. I would have thought the ifort check on ininitialised variables would have found this one.

As TimP commented it may be other code mods that now have caused these to be filled with non-zero junk rather than zero junk! I will have do dig a bit deeper to try to identify other potential bugs in my code.

@TimP, thanks for the tips, I will read further, but are there any plans to improve this aspect of fault finding in ifort?

[mecej4]

Initialization (to zero or anything else) and saving local variable values across calls are only loosely related. You wrote

 In the case of the integer the first reference was on a subroutine call so I think that is why it escapes the ifort checking, the case of the real(8) it was assigned to another variable in the same subroutine and it clearly needed to be initialised to zero have the save attrubute for subsequent calls to work.

. I cannot understand that sentence at all, but I have misgivings that it conveys hints of false assumptions which you make about how initialization works.

non-zero junk rather than zero junk

How do you distinguish between "zero junk" and "zero nonjunk"? 

[andrew_4619]

Typo. It is junk because it is uninitialiised and is taking whatever happens to be in the memory location assigned. It maybe I was getting zero before by luck.

[Steven_L_Intel1]

There has not been any change in behavior of /Qsave. As others have suggested, an incidental change in instructions used or memory layout due to optimization could have revealed a previously hidden bug. Or as some have suggested, the uninitialized value may not have been something that caused you a problem before, but now it does.

[andrew_4619]

@Steve. Yup agree with that. But  is there any plan to improve the detection of uninitialised variables, this seems to be a weakness in the otherwise well-stocked IFort armary?

[andrew_4619]

[fortran]program Console2

implicit none
real(4) a,b,c
a=1.0
c=a+b
print *, a, b, c
pause
end program Console2

[/fortran]

/nologo /Od /warn:all /module:"Release\\" /object:"Release\\" /Fd"Release\vc100.pdb" /libs:static /threads /c

Gives no errors or warnings, are there other options I need to change?

[IanH]

For info, where the subject source is your example...

(Edit: apologies, the syntax highlighter got a bit confused - as a summary Inspector-XE finds the problem, and it is detected at runtime with /check:all too.)

[plain]U:\projects\ThingsIGetUpToWhenTheWifesNotLooking>ifort /Od /warn:all /libs:static /threads /Qdiag-enable:sc "2013-07-28 uninit.f90"

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 201306
07
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

ifort: remark #10336: Static analysis complete; results available in ".\r002sc\r002sc.inspxe"

U:\projects\ThingsIGetUpToWhenTheWifesNotLooking>inspxe-cl -report problems

P1: Critical: Uninitialized variable
2013-07-28 uninit.f90(5): error #12143: "B" is uninitialized
 P1.1: Uninitialized variable: Not fixed
2013-07-28 uninit.f90(5): error #12143: "B" is uninitialized
  X1: Uninitialized read: U:\projects\FortranMisc\FortranMisc\2013-07-28 uninit.f90(5): Function MAIN_


U:\projects\ThingsIGetUpToWhenTheWifesNotLooking>ifort /Od /warn:all /check:all /libs:static /threads "2013-07-28 uninit.f90"

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 201306
07
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2013-07-28 uninit.exe"
-subsystem:console
"2013-07-28 uninit.obj"

U:\projects\ThingsIGetUpToWhenTheWifesNotLookingc>"2013-07-28 uninit.exe"

forrtl: severe (193): Run-Time Check Failure. The variable 'CONSOLE2$B' is being used without being defined
Image              PC                Routine            Line        Source
2013-07-28 uninit  000000013FFEF5A7  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFEBCB3  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFB28C6  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFA4035  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFA10A4  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFF026C  Unknown               Unknown  Unknown
2013-07-28 uninit  000000013FFDA813  Unknown               Unknown  Unknown
kernel32.dll       000000007772652D  Unknown               Unknown  Unknown
ntdll.dll          000000007785C521  Unknown               Unknown  Unknown[/plain]

[andrew_4619]

Ahh! Inspector XE , I don't have that licence (Fortran Composer XE with MKL only) I should look at a 30 trial licence to see what that can find. What are there the upgrade /add-on options?

[mecej4]

However, changing type to character(4) and using concatenation in place of addition gives a program for which the detection fails:

[fortran]

program Console2
implicit none
character(4) a,b,c
a='a'
! b='b'          ! commented out to make 'b' undefined
c=trim(a)//trim(b)
print *, a, b, c
pause
end program Console2[/fortran]

[andrew_4619]

It would appear the minimum upgrade option is to Intel® Visual Fortran Studio XE 2013 for Windows , 'studio' being the extra word that gives Vtune and Inspector for the princely sum of USD1549.

@mecej4 - Inspector fails to ID the error in your test?

[mecej4]

app4619 wrote:
 Inspector fails to ID the error in your test?

I don't know about what Inspector would do. I just compiled and ran the two examples using ifort /check:all /warn:all .

I would use a different compiler for unearthing undefined variables, anyway, given that IFort, although improving in this aspect, is still quite weak as to its error detecting and locating capabilities. Secondly, I'd rather have all errors treated the same way -- the compiler should print messages at compile time, the runtime should print a traceback at run time, and all this at the command line -- than have to run special tools for detecting each kind of error.

[andrew_4619]

mecej4 -- the compiler should print messages at compile time 

I fully agree with that, you want to find the bugs as soon as you add them wherever possible.