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

Compiler 15, Update 1 seems to hang up: parameterized derived type extension with type-bound procedures

FortranFan
Honored Contributor II
515 Views

I think the simple code below that makes use of a parameterized derived type extension with type-bound procedures is ok, but Intel(R) Visual Fortran Compiler XE 15.0.1.148 seems to hang up for me and the process never exits.  I wonder if this problem is reproducible.

MODULE m

   USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : I4 => INT32, SP => REAL32, DP => REAL64

   IMPLICIT NONE

   !..
   PRIVATE

   !..
   PUBLIC :: I4, SP, DP

   TYPE :: b_t(k,n)
      PRIVATE
      INTEGER(I4), KIND :: k = SP
      INTEGER(I4), LEN  :: n = 1
   END TYPE b_t

   TYPE, EXTENDS(b_t), PUBLIC :: e_t
      PRIVATE
      REAL(k) :: m_X(n)
   CONTAINS
      PRIVATE
      PROCEDURE, PASS(This) :: SetX_SP
      PROCEDURE, PASS(This) :: SetX_DP
      GENERIC, PUBLIC :: SetX => SetX_SP, SetX_DP
   END TYPE e_t

CONTAINS

   PURE SUBROUTINE SetX_SP(This, Arr)

      CLASS(e_t(SP,*)), INTENT(INOUT) :: This
      REAL(SP), INTENT(IN)            :: Arr(:)

      IF (SIZE(Arr) == This%n) THEN
         This%m_X = Arr
      END IF

      RETURN

   END SUBROUTINE SetX_SP

   PURE SUBROUTINE SetX_DP(This, Arr)

      CLASS(e_t(DP,*)), INTENT(INOUT) :: This
      REAL(DP), INTENT(IN)            :: Arr(:)

      IF (SIZE(Arr) == This%n) THEN
         This%m_X = Arr
      END IF

      RETURN

   END SUBROUTINE SetX_DP

END MODULE m

 

0 Kudos
18 Replies
FortranFan
Honored Contributor II
515 Views

To elaborate a little further on the above example, if the derived type is not an extended one, the code compiles without errors or warnings.

MODULE m

   USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : I4 => INT32, SP => REAL32, DP => REAL64

   IMPLICIT NONE

   !..
   PRIVATE

   !..
   PUBLIC :: I4, SP, DP

   TYPE, PUBLIC :: t(k,n)
      PRIVATE
      INTEGER(I4), KIND :: k = SP
      INTEGER(I4), LEN  :: n = 1
      REAL(k) :: m_X(n)
   CONTAINS
      PRIVATE
      PROCEDURE, PASS(This) :: SetX_SP
      PROCEDURE, PASS(This) :: SetX_DP
      GENERIC, PUBLIC :: SetX => SetX_SP, SetX_DP
   END TYPE t

CONTAINS

   PURE SUBROUTINE SetX_SP(This, Arr)

      CLASS(t(SP,*)), INTENT(INOUT) :: This
      REAL(SP), INTENT(IN)            :: Arr(:)

      IF (SIZE(Arr) == This%n) THEN
         This%m_X = Arr
      END IF

      RETURN

   END SUBROUTINE SetX_SP

   PURE SUBROUTINE SetX_DP(This, Arr)

      CLASS(t(DP,*)), INTENT(INOUT) :: This
      REAL(DP), INTENT(IN)            :: Arr(:)

      IF (SIZE(Arr) == This%n) THEN
         This%m_X = Arr
      END IF

      RETURN

   END SUBROUTINE SetX_DP

END MODULE m

 

------ Build started: Project: TestFor, Configuration: Debug|Win32 ------

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

Build log written to  "file://..\Debug\Win32\TestForBuildLog.htm"
TestFor - 0 error(s), 0 warning(s)


---------------------- Done ----------------------

 

0 Kudos
Steven_L_Intel1
Employee
515 Views

I've seen another report of this. Will check it out in detail on Monday.

0 Kudos
Steven_L_Intel1
Employee
515 Views

This is very similar, though not identical, to an issue we're already working, ID DPD200363712. I added your example to that case. Thanks.

0 Kudos
FortranFan
Honored Contributor II
515 Views

Thanks Steve.  So does it mean you/Intel can reproduce the apparent "hanging up" of Ifort.exe process with the code snippet in the original topic above?  I was worried if the process getting frozen was unique to my setup.

By the way, any idea why a forum search for issue ids doesn't work?  I've noticed this before too, but I just did a search on  DPD200363712 and no results are obtained.

0 Kudos
Steven_L_Intel1
Employee
515 Views

Yes, I can reproduce it. The other report wasn't through the forum, which is why you can't find it. The compiler is going into an infinite loop.

0 Kudos
FortranFan
Honored Contributor II
515 Views

Steve Lionel (Intel) wrote:

Yes, I can reproduce it. The other report wasn't through the forum, which is why you can't find it. The compiler is going into an infinite loop.

Steve,

Re: forum search, I did it after you posted your comment.  So shouldn't the search have come up with a hit for your comment?

I also just did a search for the issue Id  DPD200363307 you referenced in the other topic on PDTs; sorry, but the forum search comes up with no hits for this either.

Is the forum search feature only querying the topic titles and not the comments section?

0 Kudos
Steven_L_Intel1
Employee
515 Views

The index is probably not updated immediately. Then again, I've generally found searching Google with "site:software.intel.com" added to be more effective than the forum search. Google already finds my initial post.

0 Kudos
FortranFan
Honored Contributor II
515 Views

Steve Lionel (Intel) wrote:

The index is probably not updated immediately. Then again, I've generally found searching Google with "site:software.intel.com" added to be more effective than the forum search. Google already finds my initial post.

Thanks for the tip about Google!  I should have thought about it since I already do that for a couple of other sites.

0 Kudos
Steven_L_Intel1
Employee
515 Views

I expect this problem to be fixed in Update 2, planned for February.

0 Kudos
FortranFan
Honored Contributor II
515 Views

Steve Lionel (Intel) wrote:

I expect this problem to be fixed in Update 2, planned for February.

Steve,

The code in the original post gets past the hang up stage with the latest compiler update, but it encounters an internal compiler error with Intel 64 configuration (x64, 64-bit).  It compiles fine with IA-32 target (Win32, 32-bit)

------ Build started: Project: TestFor, Configuration: Debug|x64 ------

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]...
TestMod.f90
C:\..\TestMod.f90(37): 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 C:\..\TestMod.f90 (code 1)

 

0 Kudos
Steven_L_Intel1
Employee
515 Views

So it does. Unfortunate. I have reopened the issue with development.

0 Kudos
Matuszyk__Pawel
Beginner
515 Views
Hi, I think this is not a problem with a derived type, but rather with definition of the derived type itself. Here, there is a code which does not compile, however, it compiles with x(0:n)...
MODULE test
  IMPLICIT NONE
!
  TYPE, PUBLIC :: mtype(n)
    INTEGER, LEN :: n
    INTEGER      :: x(0:n+1) ! does not compile, but compiles with x(0:n)
  CONTAINS
    PROCEDURE    :: fun
  END TYPE mtype
!
  CONTAINS
!
  SUBROUTINE fun(this)
    CLASS(mtype(*))     :: this
    this%x = 0
  END SUBROUTINE fun
!
END MODULE test
Pawel
0 Kudos
FortranFan
Honored Contributor II
515 Views

Pawel Matuszyk wrote:

Hi,
I think this is not a problem with a derived type, but rather with definition of the derived type itself. Here, there is a code which does not compile, however, it compiles with x(0:n)...

 ..

Your code compiles and executes fine with the latest compiler version, 2015, Update 2 (Intel(R) Visual Fortran Compiler XE 15.0.2.179)

0 Kudos
Matuszyk__Pawel
Beginner
515 Views
Well, but I do not have the access to the newwest one... Pawel
0 Kudos
FortranFan
Honored Contributor II
515 Views

Steve Lionel (Intel) wrote:

So it does. Unfortunate. I have reopened the issue with development.

Steve,

Fyi, the code snippets in both Message  #1 and #2 now cause an ICE with compiler 16.0, update 1 with x64 target configuration (x86/Win32 compiles with no errors or warnings):

Compiling with Intel(R) Visual Fortran Compiler 16.0.1.146 [Intel(R) 64]...
m.f90
m.f90(37): 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 m.f90 (code 1)

 

0 Kudos
Steven_L_Intel1
Employee
515 Views

I get an ICE for #1 but not #2. Are you using any compile options?

0 Kudos
FortranFan
Honored Contributor II
515 Views

Steve Lionel (Intel) wrote:

I get an ICE for #1 but not #2. Are you using any compile options?

You're right, it's just for the code in Message #1.  I think I made a mistake during the cut-and-paste from this thread and perhaps didn't update the buffer while doing my test.  Thanks for catching it.

0 Kudos
Steven_L_Intel1
Employee
515 Views

The ICE should be fixed in compiler 16.0.2, planned for February.

0 Kudos
Reply