Support for Analyzers (Intel VTune™ Profiler, Intel Advisor, Intel Inspector)
4699 Discussions

No complaint about use of uninitialized variables in simple Fortran test cases?



I'm trying to use Inspector on the simple examples in the Polyhedron test suite (, but I don't get the error reports I expect.  Am I doing something wrong?

Taking UIN7 as an example, it's compiled from the command line using

ifort uin7.for      /debug:full /Od /libs:dll /threads /dbglibs

and I use the stand-alone GUI to do a "Memory Error Analysis - Locate Memory Problems" analysis, with "Detect uninitialized memory reads" checked.

The command line is:

inspxe-cl -collect mi3 -knob detect-uninit-read=true -knob revert-uninit=false -knob analyze-stack=true -knob detect-leaks-on-exit=true -knob detect-resource-leaks=true -knob enable-memory-growth-detection=true -knob enable-on-demand-leak-detection=true -knob remove-duplicates=true -knob still-allocated-memory=true -knob stack-depth=16 -mrte-mode=auto -module-filter-mode=include -app-working-dir J:\diagnose\windows -- J:\diagnose\windows\uin7.exe

At first, I do get an "uninitialized memory access", but it seems to be unrelated - I get it even if I fix the error in UIN7.

Description    Source    Function    Module    Object Size    Offset
Read    crtexe.c:536    _tmainCRTStartup    uin7.exe        
    >uin7.exe!_tmainCRTStartup - crtexe.c:536
     uin7.exe!mainCRTStartup - crtexe.c:376

With that suppressed, I get no error reports.  The other tests behave similarly.



0 Kudos
2 Replies

The uninitialized access that was found is a false positive (and can be ignored).  If you look at the stack in the source view in the GUI, it is clear it extends into the run-time library.


As for the false negative, the expected uninit access occurs in a common block, and by default the common block is located in the data section.  In the data section, there is no difference between a uninitialized value and a value initialized to zero.

One workaround is the use the '/Qdyncom' compiler option, which uses dynamic allocation for the common block. (ifort /Qdyncom aaa uin7.for).


Thanks for the quick reply Mark

However, I'm still unable to get my code to trigger a true positive for uninitalized variables.  I tried the /Qdyncom route, but it makes no difference, except that I get a "Memory not deallocated" - presumably for the dynamic common.  

The Polyhedron test set mentioned in my original post has 13 tests for use of uninitialized variables (UIN1 - UIN13) covering a variety of simple scenarios - local variables. COMMON, modules, arguments etc. - and none of them seems to trigger a true positive error message.

Thanks for your help