Segfault after referencing allocatable component of a type.

Segfault after referencing allocatable component of a type.

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)

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 
the ifort compiled code gives:
$ 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 

(note the two blank lines before segfault)

the gfortran compiled gode returns the proper result:

$ gfortran bug.f90 -o bug_gfortran && ./bug_gfortran o1 o2 o1 o1 o2 o1 
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:

$ ifort -assume realloc_lhs bug.f90 -o bug_ifort_realloc && ./bug_ifort_realloc o1 o1 o1 o1 
Sorry for the confusing post.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

I have encountered a new bug, somewhat related to the one above:

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

Again, the result after compiling with gfortran is
$ gfortran bug4.f90 -o bug4 && ./bug4

 tt(1)%a=           1

 After second reallocation:

 tt(1)%a=           1

 tt(2)%a=           2

While ifort gives
$ ifort -assume realloc_lhs bug4.f90 -o bug4 && ./bug4

 tt(1)%a=           1

 After second reallocation:

 tt(1)%a=           0

 tt(2)%a=           2

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.

Best Reply

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.

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

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

Leave a Comment

Please sign in to add a comment. Not a member? Join today