- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am using ifort (IFORT) 12.1.5 20120612
The following program fails to give the same result as GNU Fortran (GCC) 4.7.1 20120721 (prerelease)
[fortran]program table type :: option character(len=10), allocatable :: options(:) end type option type(option), allocatable :: test1(:) type(option):: test2(2) type(option) :: a1, a2 a1 % options = ["o1", "o2"] a2 % options = ["o1"] test1 = [a1,a2] test2 = [a1,a2] print *, test2(1)%options print *, test2(2)%options print *, test1(1)%options print *, test1(2)%options end program table [/fortran] the ifort compiled code gives:
[bash]$ ifort bug.f90 -o bug_ifort && ./bug_ifort forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source bug_ifort_glibc 000000000040306C Unknown Unknown Unknown bug_ifort_glibc 0000000000402B7C Unknown Unknown Unknown libc.so.6 00007FE88A6E6725 Unknown Unknown Unknown bug_ifort_glibc 0000000000402A79 Unknown Unknown Unknown [/bash]
(note the two blank lines before segfault)
the gfortran compiled gode returns the proper result:
[bash]$ gfortran bug.f90 -o bug_gfortran && ./bug_gfortran o1 o2 o1 o1 o2 o1 [/bash] Regards,
Pawe Biernat.
EDIT:
In the above example I forgot to add the -assume realloc_lhs option, honce the segfaults. But even with realloc_lhs the output is different then expected:
[bash]$ ifort -assume realloc_lhs bug.f90 -o bug_ifort_realloc && ./bug_ifort_realloc o1 o1 o1 o1 [/bash] Sorry for the confusing post.
- 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
I have escalated this issue with "-assume realloc_lhs" to the developers. The issue number is DPD200235134. I will keep you informed of any updates Ireceive on this issue.
Regards,
Annalee
Intel Developer Support
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[fortran]program bug type :: t integer, allocatable :: a end type t type(t), allocatable :: tt(:) type(t) :: t1, t2 t1%a = 1 t2%a = 2 ! allocate zero sized array allocate(tt(0)) ! should reallocate tt = [tt,t1] print *, "tt(1)%a=", tt(1)%a ! again, array reallocation tt = [tt,t2] print *, "After second reallocation first entry is lost:" print *, "tt(1)%a=", tt(1)%a print *, "tt(2)%a=", tt(2)%a end program bug [/fortran] Again, the result after compiling with gfortran is
[bash]$ gfortran bug4.f90 -o bug4 && ./bug4 tt(1)%a= 1 After second reallocation: tt(1)%a= 1 tt(2)%a= 2 [/bash] While ifort gives
[bash]$ ifort -assume realloc_lhs bug4.f90 -o bug4 && ./bug4 tt(1)%a= 1 After second reallocation: tt(1)%a= 0 tt(2)%a= 2 [/bash] The compiler versions are the same as above.
The release notes indicates, that the following is supported by ifort:
"Reallocation of allocatable variables on the left hand side of an assignment statement
when the right hand side differs in shape or length (requires
option -assume realloc_lhs if not deferred-length character)"
but it seems to be an overestimation of the current state.
Best regards,
Pawe.
- 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
Pawe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Annalee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A fix has been found for this issue, we are currently planning to include it in the next major release which is scheduled for later this year.
Annalee
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page