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

17.07, 18.03 and 19.0 crash when moving functions into submodules

may_ka
Beginner
279 Views

FYI,

all >16 ifort compilers crash when compiling the following code:

Module Mod_String
  Implicit None
  Private
  Type, Public :: String
  contains
    Procedure, Pass :: GrepF => FunGrepF
  End type String
  Interface
    Module Function FunGrepF(this) result(x)
      Class(String), Intent(InOut) :: this
      Logical :: x
    end function
    ! !!@@@@@@@@@@@@@@@@@@@@@@@@
    ! !!workaround
    ! Module Function FunGrepF(this)
    !   Class(String), Intent(InOut) :: this
    !   Logical :: FunGrepF
    ! end function
    ! !!@@@@@@@@@@@@@@@@@@@@@@@
  End Interface
End Module Mod_String
SubModule(Mod_String) UTE
contains
  Module Procedure FunGrepF
    Implicit none
  End Procedure
End SubModule UTE
Module Mod_LM
  Implicit None
  Type, Abstract :: LM
  contains
    Procedure(Subiii), Pass, Public, Deferred :: iii
  End type LM
  Abstract Interface
    Subroutine Subiii(this,TSSPoly)
      use Mod_String, only: String
      Import LM
      Class(LM), Intent(InOut) :: this
      Type(String), Intent(In), optional :: TSSPoly
    End Subroutine Subiii
  End Interface
End Module Mod_LM

The problem is the "result(x)" definition in the interface block, but the problem will only turn up if the type of which function was declared that way is eventually imported into an abstract interface block .............................. really hard to track down bug which may cause some sleepless nights when recompiling commercial applications after some "harmless" code reshaping.

A support ticket has been submitted.

cheers

0 Kudos
3 Replies
Juergen_R_R
Valued Contributor I
279 Views

Yes, confirmed. 

0 Kudos
FortranFan
Honored Contributor II
279 Views

Hopefully Intel Fortran team can resolve the internal compiler error with this case soon.

Just FYI for readers, another workaround the ICE can be to avoid the USE statement within the scope of INTERFACEs and stick to IMPORT instead; in other situations, this approach with IMPORT can be of some help with compactness, consistency, and clarity of coding instructions as well:

module Mod_LM
   use Mod_String, only: String   !<--  USE statement moved to MODULE level scope
   implicit none
   type, abstract :: LM
   contains
      procedure(Subiii), pass, public, deferred :: iii
   end type LM
   abstract interface
      subroutine Subiii(this,TSSPoly)
         import :: String, LM    !<--- String declaration is imported
         implicit none
         class(LM), intent(inout) :: this
         type(String), intent(in), optional :: TSSPoly
      end subroutine Subiii
   end interface
end module Mod_LM

 

0 Kudos
may_ka
Beginner
279 Views

FortranFan wrote:

Just FYI for readers, another workaround the ICE can be to avoid the USE statement within the scope of INTERFACEs and stick to IMPORT instead; in other situations, this approach with IMPORT can be of some help with compactness, consistency, and clarity of coding instructions as well:

Thanks. Didn't actually know that "import" and "use" are interchangeable in some situations.

0 Kudos
Reply