- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page