Internal compiler error: segmentation violation signal raised

[Sebastien_B_]

Dear support team,
please find below a sample program which raises an ICE with the latest version of ifort (downloaded today). I reproduce all the necessary details. I can not attach the program ("you are not authorized to open this page"), so I copy it below.
Thanks,
Sebastien

tmp> ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.080 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.
30 DAY EVALUATION LICENSE

ifort: NOTE: The evaluation period for this product ends on 23-nov-2013 UTC.

tmp> ifort -c -module ./ -O bug-ifort-14.0.0.f90   
bug-ifort-14.0.0.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.                                                                 
compilation aborted for bug-ifort-14.0.0.f90 (code 1)

tmp> uname -a
Linux bardeau 2.6.32-358.18.1.el6.x86_64 #1 SMP Tue Aug 27 14:23:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux

tmp> cat bug-ifort-14.0.0.f90
module gtv_protocol
  !
  integer(kind=4) :: gtblz1
  character(len=4) :: name1(1)
  !
  ! Some compilers need a strict correspondance in the number of
  ! bytes between the common and the variable we want to equivalence.
  ! gtblz_padding is here to fill the common up to the size of buftbl.
  ! No need to use it out of this module => make it private
  integer(kind=4), private :: gtblz_padding(126)
  !
  common /gtblz/ gtblz1,name1,gtblz_padding
  !
  integer(kind=4) :: buftbl(128)
  equivalence (gtblz1,buftbl)
  !
end module gtv_protocol
!
module gtvdef_variables
  use gtv_protocol
end module gtvdef_variables
!
module my_interfaces
  interface
    subroutine list_out(line)
      use gtvdef_variables
      character(len=*) :: line
    end subroutine list_out
  end interface
  !
end module my_interfaces
!
subroutine gtv_c(line)
  use my_interfaces
  character(len=*) :: line
  call list_out (line)
end subroutine gtv_c
 

[Kevin_D_Intel]

Thank you for the convenient reproducer. Unfortunately this is also still reproducible in our upcoming Composer XE SP1 Update 1. I will report this to our Developers and keep you updated about a fix and post again if there is any temporary source code change to work around this.

(Internal tracking id: DPD200248209)
(Resolution Update on 09/09/2014): This defect is fixed in the Intel® Composer XE 2013 SP1 Update 2 release (2013.1.2.144 - Linux)

[Kevin_D_Intel]

The error occurs in relation to the nested modules so there may not be a usable source change to work around this. For the small reproducer, the error does not occur with use gtv_protocol inside the interface vs. use gtvdef_variables. That may also be something you found in creating the reproducer.

I will let you know whether Development finds any work around.

[Kevin_D_Intel]

We received earlier reports of this error and will have a fix in an upcoming Composer XE 2013 SP1 update (tentatively early next year).

Another work around was identified where removing private also avoids the error. I don't know whether that is usable in the original app either.

I will update this post when an compiler update containing the fix is available.

[Sebastien_B_]

Kevin Davis (Intel) wrote:

The error occurs in relation to the nested modules so there may not be a usable source change to work around this. For the small reproducer, the error does not occur with use gtv_protocol inside the interface vs. use gtvdef_variables. That may also be something you found in creating the reproducer.

I will let you know whether Development finds any work around.

Indeed, I found that avoiding nested modules solved the problem. However, in my real program, I removed the 'private' flag on the variable gtblz_padding as a workaround, since it does not harm to leave this variable public.

[Kevin_D_Intel]

My apologies Sebastien. I overlooked notifying you about the availability of this fix early this year in the CXE 2013 SP1 Update 2 release (14.0 compiler). At that same time the error was also fixed for 15.0 compiler in the most recent Intel Parallel Studio XE 2015 release.

[Sebastien_B_]

Thanks for the feedback. In the end, I choose to suppress the "private" since it is not really needed.