topic Internal compiler error: segmentation violation signal raised in Intel® Fortran Compiler

Internal compiler error: segmentation violation signal raised

Sebastien_B_ — Thu, 24 Oct 2013 15:37:08 GMT

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

Thank you for the convenient

Kevin_D_Intel — Thu, 24 Oct 2013 17:46:00 GMT

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)

The error occurs in relation

Kevin_D_Intel — Thu, 24 Oct 2013 18:06:16 GMT

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.

We received earlier reports

Kevin_D_Intel — Fri, 25 Oct 2013 09:13:26 GMT

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.

Quote:Kevin Davis (Intel)

Sebastien_B_ — Mon, 28 Oct 2013 08:36:52 GMT

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.

My apologies Sebastien. I

Kevin_D_Intel — Tue, 09 Sep 2014 18:43:44 GMT

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.

Thanks for the feedback. In

Sebastien_B_ — Mon, 15 Sep 2014 15:12:28 GMT

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