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

[johnappleyard377]

Hi

I'm trying to use Inspector on the simple examples in the Polyhedron test suite (http://www.polyhedron.com/wp-content/uploads/2014/04/win32_diagnose_src.zip), 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!main
    >uin7.exe!_tmainCRTStartup - crtexe.c:536
     uin7.exe!mainCRTStartup - crtexe.c:376
     kernel32.dll!BaseThreadInitThunk
     ntdll.dll!RtlInitializeExceptionChain

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

[Mark_D_Intel]

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).

[johnappleyard377]

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

John