Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Debug error from C++ RTL


I am trying to use the latest Intel Fortran compiler ( My program compiles fine but when I run the Debug version (I didn't try the Release version), I get a C++ RTL error:

Debug Error! Damage before (some memory address) which was allocated by aligned routine.

The error is occurring at two locations:

1. When I call a function that returns an array of user-defined data type that includes ALLOCATABLE array attributes. I was able to fix this by converting these functions to subroutines.

2. When I try to DEALLOCATE an array of user-defined data type that includes ALLOCATABLE array attributes. Maybe I should first deallocate the attributes before attempting to deallocate the array?

This code worked fine with and earlier versions of the compiler. Can this be an issue with the compiler? Any help will greatly be appreciated.


EDIT: For item 2 above, it turns out that the error occurs if one of the array arguments of the user-defined type is not previously allocated. I use the STAT argument with DEALLOCATE to avoid checking if an array is allocated before deallocating it. This has always worked in the past.

0 Kudos
2 Replies

Interesting. Thank you for your post. We recently received another reported sighting of this message,

Development is still investigating this earlier case. It would really be instructive to us if you could provide a complete reproducer for your case that covers both locations you noted. Is that possible?



Unfortunately, I can't replicate the issue with a simple program. The original code includes several levels of user-defined types (UDT) being used for array arguments in other UDTs. I will have to submit the original code to the premier support.

However, digging into this a bit more, I discovered that the deallocation issue in item 2 above is also related to the constructor being coded as a FUNCTION. When the constructor is converted to a SUBROUTINE, I don't have any issues with deallocating the array arguments of the variable.