Segfault after referencing allocatable component of a type.

[pwl_b]

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.

[Anonymous66]

Hello Pawel,

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

[pwl_b]

I have encountered a new bug, somewhat related to the one above:
[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.

[IanH · Accepted solution]

The article at http://software.intel.com/en-us/articles/incorrect-results-assigning-array-constructor-with-allocatable-components/ might be of interest.

[pwl_b]

Would you mind to explain why -stand 08 does not imply -assume realloc_rhs? It seems that reallocatable arrays are included in standard Fortran 2008.

Pawe.

[Anonymous66]

The -stand 08 option only turns on standards checking. The "-standard-semantics" option will set "-realloc_lhs" and other options that comply with the most recently implemented version of the standards.

Annalee

[Anonymous66]

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