Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29375 Discussions

Data corruption with allocatable class elements in derived type

thomas_boehme
New Contributor II
825 Views

Hello,

We are currently using the latest official build of IVF (2011 Update 11) and are still experiencing quite a few problems (corrupt data, seg faults) when using allocatable class elements in derived types. Unfortunately, so far we couldn't create simple reproducers for some of our problems. However, we succeeded in creating one simple reproducer for at least one case of data corruption when using allocatable class elements in a derived type.

In the following sample code, setting ClassMain%AllocType%c corrupts the value of ClassMain%AllocType%i (Note, this also happens with a pointer element instead of allocatable).

The problem seems to happen regardless of build options.

regards,
Thomas
PS: The debugger shows different values for ClassMain%AllocType%i than printed. We also have experienced such behavior quite often.

[fortran]




PROGRAM Test1 IMPLICIT NONE TYPE :: tAlloc REAL(8) :: a INTEGER(4) :: i REAL(8) :: b REAL(8) :: c END TYPE TYPE :: tClassMain LOGICAL :: f ! note, these unused fields are required to recreate the problem. REAL(8) :: d ! removing any of these, makes the problem go away (or at least invisible) CLASS(tAlloc), ALLOCATABLE :: AllocType ! The problem occurs only with class here. Type works fine. END TYPE TYPE(tClassMain) :: ClassMain ALLOCATE(tAlloc::ClassMain%AllocType) ClassMain%AllocType%i = 1 ClassMain%AllocType%a = 0.6789D0 WRITE(*,*) ClassMain%AllocType%i ! Here, i is 1 as expected. ClassMain%AllocType%c = 0.12345D0 WRITE(*,*) ClassMain%AllocType%i ! Here, after writing c, i is changes as well and now reads 1353773692 END PROGRAM Test1 [/fortran]

 

0 Kudos
1 Solution
Steven_L_Intel1
Employee
825 Views
I can reproduce this in 12.1.5 but not in the 13.0 compiler due out in a few weeks.

View solution in original post

0 Kudos
3 Replies
Steven_L_Intel1
Employee
826 Views
I can reproduce this in 12.1.5 but not in the 13.0 compiler due out in a few weeks.
0 Kudos
thomas_boehme
New Contributor II
825 Views

Hi Steve,

thanks for the info. I hope that we will be able to migrate our code to the new compiler then. Is there any chance that this will get fixed within the 12.x series as well?

regards,
Thomas

0 Kudos
Steven_L_Intel1
Employee
825 Views
No - we've already closed the last 12.1 update and this fix is not included.
0 Kudos
Reply