False positives with Fortran derived types

[michel_lestrade]

Hi,

I am getting some uninitialized memory access errors with a derived type containing allocatable arrays which I believe are false positives.

If I use a subroutine with an intent(out) parameter to initialize the derived type and allocate its member arrays, the Inspector does not complain. However, if I have a function which returns the object the very same code gives an Intel Inspector error in memcpy.asm during the allocate() statement. I'm no expert but at the point of the error, the arrays in question are supposed to be unitialized; they're inside an allocate statement ....

Besides the Inspector errors, I have another Inspector warning which I cannot explain and which also seems like a false positive. My objects have a final subroutine which is being called to deallocate the member arrays as the object loses scope; this routine gets called correctly as I can step through it in the debugger. If I create my object inside a foo() subroutine, the Inspector reports everything is OK on that point but creating the object directly inside the program block gives a warning about unallocated memory when the program exits.

Attached to this is test source file to reproduce the errors and the corresponding Intel Inspector log (mi3). Compilation environment is 32-bit Debug with Visual Studio 2008 SP1 and Intel(R) Composer XE 2013 SP1 Update 2 (package 176). The Intel Inspector is Update 9 (build 328075).

The code itself runs correctly as far as I can tell and I would prefer to use the function style instead of subroutines since it would clarify the rest of the program later on.

Regards,

Michel Lestrade

[Mark_D_Intel]

The compiler is apparently creating a temporary sparse_csr object, and then copying the contents to A in the main program.   That copy is the source of the uninitialized memory reads.  If the mat,colind, and rowptr arrays are set to zero in the new_csr function, these errors go away.   Or if these arrays are changed to 'pointer' rather than 'allocatable', they are no longer copied, and no uninitialized reads are reported (but this change may be incompatible with deallocating the memory in the finalizer - I commented out all the deallocation lines for this test.)

With a print statement in the finalizer, two lines get printed out during execution.   If the A variable in the main program is changed to be allocatable, and allocated and deallocated appropriately, there are three lines printed from the finalizer, and IXE reports no unallocated memory warnings.   So apparently, static variables (as A was originally defined) will not have the finalizer called (I'm not really certain about how Fortran finalizers are supposed to behave).   So IXE is correct in that the memory allocated as a part of A was not deallocated.

[michel_lestrade]

Mark,

Your explanation makes sense given that the IXE does not report an error with the same code when returning the result via a subroutine's intent(out) parameter instead of using a function. If there is a temporary copy being made when using a function output, then that might explain why the behavior is different in these two cases.

I was under the impression that Fortran passed everything by reference by default but I guess this does not hold true for function outputs. If I were to use C++ lingo, I guess this means a typical Fortran function prototype would be object myfunc(void) rather than object& myfunc(void).... However, I had thought of that before and checked the %LOC of the output both inside and outside the function and they seemed to be the same; I guess this was not a good test ...

Anyway, I certainly want to avoid making unnecessary copies of what will be large sparse matrix data so I will be using a subroutine from now on. Thanks for the help.