Incorrect uninitialized partial memory access

[David_Bal]

I get a strange error with Inspector XE 2013.  The problem occurs when I try to access a derived data type that contains an int16 integer.  Intel Inspector says there is an uninitialized partial memory access error.  All variables are initialized.  The problem disappears if the integer type is changed to int32.  The attached code shows the problem.  My code was built with the latest Intel Fortran Composer XE 2013.  Any solutions?

[Peter_W_Intel]

Thanks for your test case, but I cannot reproduce this problem. I didn't modify code - it should be int16 integer defined... I used Intel Fortran compiler, Inspector XE 2013 U2: Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 1 3.0.1.119 Build 20121008 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. Intel(R) Inspector XE 2013 Update 2 (build 250094) Command Line tool Copyright (C) 2009-2012 Intel Corporation. All rights reserved. C:\temp\tmp>ifort -debug problem.f90 -o problem.exe Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 1 3.0.1.119 Build 20121008 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:problem.exe -debug -pdb:problem.pdb -subsystem:console problem.obj C:\temp\tmp>inspxe-cl -collect mi3 -- pro Used suppression file(s): Original Order 4 1 3 2 2 3 1 4 0 5 Reverse Order 0 5 1 4 2 3 3 2 4 1 0 new problem(s) found

[David_Bal]

One difference between your run and mine is that I used the Inspector XE GUI in Linux (64-bit Ubuntu 12.04). It appears you used Windows. I don't have access to a Windows version. Can you try again on Linux?

[Peter_W_Intel]

You are right. I saw this problem on Linux, it never occurred on Windows. Will keep further investigating, and post more if any progress.

[Mark_D_Intel]

The issue is empty padding in the structure. In order to maintain alignment, the derived type is laid out with two bytes (for the element 'value'), then two empty bytes, then four bytes (for the element 'original_order'). You can use the 'loc' function and print out the addresses of these fields to verify this. The copy in line 36 (temp = a(i)) copies all the bytes in the structure, regardless of whether they are valid or not. Inspector should be able to detect structure copies with holes, but it is apparently not working in this case. To demonstrate this, add 'sequence' to the derived type. It will force the values to packed regardless of alignment (the compiler issues a warning about misaligned fields), and the problem reported by IXE disappears. To be clear the definition of the type becomes: type combo sequence integer (kind value_kind) :: value integer (kind int32) :: original_order end type combo This also appears to be 32/64 bit issue. Peter compiled it 32 bit, and that is probably why he could not reproduce the problem. Another way to deal with the issue is to suppress it from the GUI (context menu from the lower pane in on the 'Summary' tab)

[Peter_W_Intel]

Mark is right! I can reproduce this problem by building case as Intel64, on Intel64 platform. The issue is uninitlized padding data (32bit) in 64bit data structure, not an Inspector XE's bug. See similar case - http://software.intel.com/en-us/forums/topic/280825