allocate with NaN

[Intel_C_Intel]

Hello,

I am trying to make my own version of the Fortran "allocate" function, that does exactly the same as allocate, but that also initiaites all values in the array to NaN. I have called this function "trallocate" meaning trap-allocate, as it will make it easier to trap bugs related to using arrays before they have been given a meaningful value.

My only question is how I should implement this function? I have replaced all "allocate(X,(N))" statements with "call trallocate(X(N))", but how should I transfer the value N to trallocate? Do I have to implement this in C/C++ or ASM to make this work? Is it possible to learn how the compiler has implemented the intrinsic Fortran allocate to make it possible write a proper trallocate?

Best Regards,

Lars Petter Endresen

Message Edited by lpe@scandpowerpt.com on 02-24-2006 08:03 AM

Message Edited by lpe@scandpowerpt.com on 02-24-2006 08:05 AM

[Jugoslav_Dujic]

You need exactly this. Just insert the file in your project, set /force:multiple and don't change ALLOCATE statements.

Update: it appears to produce problems (heap corruption during deallocation) when a dll-based RTL is used. I am not sure why it happens – I know it is not allowed to allocate on one module's heap and deallocate on the other's. However, I don't see how it happens, because I'd suppose that both real allocation and deallocation end up in RTL.dll. Be aware however.

Message Edited by JugoslavDujic on 03-02-2006 12:08 PM

[jim_dempsey]

Call a fill routine that treats the array of real(4) or real(8) as integer(4) or integer(8) and insert the bit pattern that represents the NaN. See:

http://stevehollasch.com/cgindex/coding/ieeefloat.html

For info on bit patterns.

Jim Dempsey

[Intel_C_Intel]

Hello,

Thanks a lot for the very useful help guys! I will try what you recommend and tell you how it works. This could have been a part of the compiler also, for example with a compiler option that changes the behaviour of allocate to initiate everything to NaN.

Best Regards,

Lars Petter Endresen

[Intel_C_Intel]

Hello,

The proposed function (attached)did not work so well with IVF 9.0 as it caused exception in too many deallocate statements without any noticeable errors in the arrays. I will try to figure out what happened.

Lars Petter

[Intel_C_Intel]

Hello,

I am sorry. Actually the proposed function works indeed very well. It is most useful. Thank you!

Lars Petter

[Intel_C_Intel]

Hello again,

I was just wondering whether there are any unititalized variables that I am not able to trap now. I am usingthese options:

/Zi /Od /fpp /free /warn:all /warn:declarations /warn:unused /warn:ignore_loc

/warn:truncated_source /warn:interfaces /real_size:64 /fpe:0 /fpconstant /traceback

/check:bounds /RTCu /libs:static /threads /dbglibs /c

togther with the suggested "NaN-allocate". What about fixed/static arrays?

Best Regards,

Lars Petter Endresen

Message Edited by lpe@scandpowerpt.com on 03-01-2006 08:26 AM

[jim_dempsey]

Try union of your real(4) or real(8) array with an integer(4) or integer(8) array then initialize the integerarray with the bit pattern of the NaN.

Jim Dempsey

[Intel_C_Intel]

Update: it appears to produce problems (heap corruption during deallocation) when a dll-based RTL is used. I am not sure why it happens I know it is not allowed to allocate on one module's heap and deallocate on the other's. However, I don't see how it happens, because I'd suppose that both real allocation and deallocation end up in RTL.dll. Be aware however.

We avoided this problem by replacing a few allocatables with pointers, do not ask me why, but now it works nicely:

if (allocated(X)) deallocate(X) replaced with if (associated(X)) deallocate(X)

The proposed function is in fact so tremendously useful that we are now using it by default in DEBUG mode.

Regards,

Lars Petter

[Jugoslav_Dujic]

Sorry for late reply. If you use pointers, as far as I know you won't get a NaN-allocate -- for_alloc_allocatable, as its name says, is invoked only for allocatables. I think allocate(pointer) calls for_allocate directly, skipping NaN initialization.

[Intel_C_Intel]

That explains why we had to do this trick. For the most part we use allocatables, but we are using some pointers also, and I guess that there is

no similar solution for pointers?

Lars Petter

[Jugoslav_Dujic]

Note that all of my knowledge about it came by means of "reverse-engineering". IOW, I stepped through the assembly code of original ALLOCATE statement and reached the conclusion that the original for_alloc_allocatable is a simple wrapper around for_allocate (which further goes deep into C run-time library or VirtualAlloc or HeapAlloc or whatever, didn't investigate deeper). So, I saw the opportunity to replace it with my own simple version. I think that allocate(pointer) goes straight into for_allocate, and reverse-engineering that could be difficult. So, offhand, for_alloc_allocatable seems to be the only place where one can do the "tweak" relatively simply.

You can step into ALLOCATE(pointer) in disassembly view and see if I'm right, and whether for_allocate calls something else and returns relatively soon.

[Intel_C_Intel]

Hello,

Thanks again. The solution you have provided is most useful for us. As it is so useful indeed, I have posted a premier support issue on the topic, with reference to this thread, and I hope that it will be implemented in the Intel compiler as a new option, in the not toodistant future. The new compiler option will hopefully also cover pointers.

Lars Petter (now following IDF 2006 San Francisco - doubling SSE execution speed is indeed impressing - congratulations to Intel!)