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

Parametrized derived type in another parametrized type

Dmitry_D
Beginner
710 Views

Hello,

I've found some important issues with the Intel Fortran compiler (ifort version 19.0.2.187) trying to use an object of one parametrized derived type in another parametrized derived type.

The following type declarations are compiled without any error: 

TYPE T1 (M)
INTEGER, LEN :: M
REAL V (M)
END TYPE T1

TYPE T2 (M, N)
INTEGER, LEN :: M, N
TYPE(T1(M=M)) V1
REAL V2 (N)
END TYPE T2

TYPE T3 (N)
INTEGER, LEN :: N
TYPE(T1(M=N)) V1
REAL V2 (N)
END TYPE T3

 

As you can see, V1 of type T1 is a member of types T2 and T3.

If I try to declare a local variable of type T2, the following error occurs:

internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
 TYPE(T2(M=2, N=3)) A
^
[ Aborting due to internal error. ]

 

The same kind of error takes place if any procedure has a dummy argument of type T2:

internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
TYPE(T2(*,*)), INTENT(IN) :: A
^
[ Aborting due to internal error. ]

 

The situation is not better if I declare a variable of type T3:

TYPE(T3(N=3)) A

This results in the following error:

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.

 

What do you think about these issues?

Thanks

0 Kudos
5 Replies
FortranFan
Honored Contributor II
703 Views

 

Dmitry_D wrote:
.. I've found some important issues with the Intel Fortran compiler (ifort version 19.0.2.187) trying to use an object of one parametrized derived type in another parametrized derived type. ..
..
What do you think about these issues?

 

 

Welcome to the club, you're not the first to find these issues.  If your license terms includes support, please submit requests to review these problems at the Intel Online Service Center: https://supporttickets.intel.com/?lang=en-US

In the absence of a reasonably featured generics/template/metaprogramming facilities in Fortran, parameterized derived types - introduced all the way back in Fortran 2003 standard revision, can really prove valuable in a number of situations for typical Fortran coding needs that involve 'parameterized' designs of one 'classes' (to borrow an OO term).  Unfortunately, the compiler support for this feature is very spotty and one encounters an internal error or ICE often and that's essentially a compiler bug.  Getting the compiler team to resolve such errors is the only recourse, so submit away all the errors you face.

0 Kudos
Steve_Lionel
Honored Contributor III
686 Views

Also fails in the 2021 Beta 8 compiler, with the additional line of:

Internal error store_pdtlen_data_space: Cannot find record

I've seen this error before, though I don't know if it resembled your test code. Please do report it using the Online Service Center.

0 Kudos
Dmitry_D
Beginner
667 Views

Hello,

I appeciate very much your feedbacks to my post. It seems that the Fortran compiler still needs improvements to allow using all potential of parametrized derived types.

Personally I don't have access to Intel Compiler Support but I'll send a request to our informatic assistance. Hopefully they'll be able to ask Intel for a fix.

Best regards

0 Kudos
Steve_Lionel
Honored Contributor III
652 Views

PDTs with length parameters are more difficult to implement than anyone imagined when they were first proposed for Fortran 2003. One popular compiler got it so completely wrong that the developers advise users to avoid them. The Intel compiler does a pretty good job, but there are some unusual usages that still trip it up.

0 Kudos
Dmitry_D
Beginner
622 Views

Hello Steve,

I do believe that the compiler developers do their best to implement new Fortran functionalities.

 

For those who are interested in the topic of this post, I can propose two quick solutions.

One is to extend T1 as follows:

TYPE, EXTENDS(T1) :: T2 (N)
INTEGER, LEN :: N
REAL V2 (N)
END TYPE T2

This works fine with the compiler versions 18 and later. It has however obvious limitations.

 

Another solution is to declare V1 as allocatable in T2. A complete example is: 

MODULE TYPES_M

TYPE T1 (M)
   INTEGER, LEN :: M
   REAL V (M)
END TYPE T1

TYPE T2 (M, N)
   INTEGER, LEN :: M, N
   TYPE(T1(:)), ALLOCATABLE :: V1
   REAL V2 (N)
CONTAINS
   PROCEDURE ALLOC => ALLOC_T2
END TYPE T2

CONTAINS

SUBROUTINE ALLOC_T2 (A)
TYPE(T2(*,*)), INTENT(OUT) :: A

ALLOCATE (T1(M=A%M) :: A%V1)

END SUBROUTINE ALLOC_T2

END MODULE TYPES_M

 

USE TYPES_M

TYPE(T2(M=2, N=3)) A

CALL A%ALLOC

Here we need to call the type-bound procedure for each object of type T2. More coding is still needed if we want to use an array of type T2.  

 

0 Kudos
Reply