Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29235 Discussions

Internal Compiler Error with with Intel(R) Visual Fortran Compiler XE 13.1.1.171 [IA-32]

FortranFan
Honored Contributor III
715 Views

Steve,

The following code generates an internal compiler error (ICE).  I am able to work around by wrapping the offending code (i.e., per compiler complaint) in a separate function.  As you have explained in many posts, an ICE is always a compiler bug.  So will it be possible to open up a defect incident for this error?

Thanks,

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.1.171 [IA-32]...

TestClass_ICE.f90

04010002_1529

..\TestClass\sor\TestClass_ICE.f90(79): catastrophic error: **Internal compiler error: internal abort** 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 ..\TestClass\sor\TestClass_ICE.f90 (code 1)

Build log written to  "file://..\TestClass\Debug\Win32\TestClassBuildLog.htm"

TestClass - 1 error(s), 0 warning(s)

[fortran]

   MODULE TestClassMod

  

 

      INTEGER, PARAMETER :: I4B = SELECTED_INT_KIND(9)

      INTEGER, PARAMETER :: DP  = SELECTED_REAL_KIND(15,307)

     

!.. Accessor class

      TYPE, ABSTRACT :: MyPropClassAbstract

      CONTAINS

         PRIVATE

         PROCEDURE(GetAbstract), PASS(This), DEFERRED :: Get

         PROCEDURE(SetAbstract), PASS(This), DEFERRED :: Set

         GENERIC, PUBLIC :: ASSIGNMENT(=) => Get, Set

      END TYPE MyPropClassAbstract

     

!.. Abstract Interface for Get, Set methods

      ABSTRACT INTERFACE

     

         ELEMENTAL SUBROUTINE GetAbstract(Value, This)

            IMPORT :: MyPropClassAbstract

            CLASS(*), INTENT(OUT)                    :: Value 

            CLASS(MyPropClassAbstract), INTENT(IN)   :: This

         END SUBROUTINE

        

         ELEMENTAL SUBROUTINE SetAbstract(This, Value)

            IMPORT :: MyPropClassAbstract

            CLASS(MyPropClassAbstract), INTENT(OUT) :: This

            CLASS(*), INTENT(IN)                    :: Value 

         END SUBROUTINE

        

      END INTERFACE

     

      !.. Real Type

      TYPE, EXTENDS(MyPropClassAbstract), PUBLIC :: MyRealProp

         PRIVATE

         REAL(DP) :: MyValue

      CONTAINS

         PROCEDURE, PASS(This) :: Get => GetReal

         PROCEDURE, PASS(This) :: Set => SetReal

      END TYPE MyRealProp

            

!.. All entities private

      PRIVATE

!.. Test Class

      TYPE, PUBLIC :: TestClass

     

         PRIVATE

        

         !.. Internal class elements

         TYPE(MyRealProp)             :: MyT

        

      !.. Class methods

      CONTAINS

     

         !.. Private by default

         PRIVATE

        

         !.. Public methods

         PROCEDURE, PASS(This), PUBLIC :: set_T

        

      END TYPE TestClass

  

   CONTAINS

  

      !  Subroutine to set temperature

      SUBROUTINE set_T(This, UomLabel, Value)

     

         !.. Argument list

         CLASS(TestClass), INTENT(INOUT) :: This

         CHARACTER(LEN=*), INTENT(IN)    :: UomLabel

         REAL(DP), INTENT(IN)            :: Value

        

         This%MyT = Value

        

         SELECT CASE(UomLabel(1:1))

            CASE("K")

               This%MyT = Value

            CASE("C")

               This%MyT = Value + 273.15_dp   !.. Compiler doesn't seem to like this: bad code or compiler bug?

            CASE DEFAULT

            ! Insert Error handling here

         END SELECT

        

      END SUBROUTINE set_T

        

      !.. Get value of Real type

      ELEMENTAL SUBROUTINE GetReal(Value, This)

     

         !.. Argument list

         CLASS(*), INTENT(OUT)         :: Value

         CLASS(MyRealProp), INTENT(IN) :: This

        

         !.. Process based on input type

         SELECT TYPE (Value)

            TYPE IS (REAL(DP))

               Value = This%MyValue

            CLASS DEFAULT

            !.. Insert error handling here

         END SELECT

     

      END SUBROUTINE GetReal  

      !.. Set value of Real type

      ELEMENTAL SUBROUTINE SetReal(This, Value)

     

         !.. Argument list

         CLASS(MyRealProp), INTENT(OUT) :: This

         CLASS(*), INTENT(IN)           :: Value

        

         !.. Process based on input type

         SELECT TYPE (Value)

            TYPE IS (REAL(DP))

               This%MyValue = Value

            CLASS DEFAULT

            !.. Insert error handling here

         END SELECT

     

      END SUBROUTINE SetReal  

   END MODULE TestClassMod

 [/fortran]

 

0 Kudos
7 Replies
Steven_L_Intel1
Employee
715 Views

Thanks - I'll look at this and enter a defect report as needed. Feel free to use this forum to report such problems.

0 Kudos
Steven_L_Intel1
Employee
715 Views

Escalated as issue DPD200244716.

0 Kudos
Steven_L_Intel1
Employee
715 Views

Here's a workaround.  Declare a local variable of the same type as Value, say, Value_local. Then replace:

This%MyT = Value + 273.15_dp

with:

Value_local = Value + 273.15_dp
This%MyT = Value_local

0 Kudos
FortranFan
Honored Contributor III
715 Views

Thanks much Steve.  I assume the ICE will still be investigated as part of issue DPD200244716?  And hopefully fixed in a later release?

As I indicated in my original posting, a separate function is normally to be used for the math in a sub like this set_T in this project.  When the SELECT CASE construct was replaced with this function call, the ICE also disappeared.

Any explanation as to why the workarounds are able to get around the ICE?  Is it something to do with stack corruption?

 

0 Kudos
Steven_L_Intel1
Employee
715 Views

It's not stack corruption - just an inadequate code path in the compiler that isn't prepared to deal with some particular issue with this defined assignment and an arithmetic expression. Yes, the ICE is being investigated and will be fixed - but I thought you'd want to see a workaround if you wanted to continue developing until the fix is available.

0 Kudos
Steven_L_Intel1
Employee
715 Views

This problem has been fixed for a release later this year.

0 Kudos
FortranFan
Honored Contributor III
715 Views

Excellent, thanks much for great support.

I can only hope now that the release that includes this fix comes out before my subscription ends or that my organization responds positively to my plea and funds the renewal of my subscription! :-)

0 Kudos
Reply