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

Internal error using parameter while having constructor with the same name as derived type

gzengm
Novice
1,323 Views

Minimal reproducible code snippet:

 

module vector3d_module
   implicit none
   type :: vector3d_type
      real :: x = 0.0
      real :: y = 0.0
      real :: z = 0.0
   end type vector3d_type

   type(vector3d_type), parameter :: vector3d_zero = vector3d_type(0.0, 0.0, 0.0)

   interface vector3d_type
      module procedure vector3d_constructor
   end interface

contains

   function vector3d_constructor() result(res)
      implicit none
      type(vector3d_type) :: res

      res = vector3d_zero
   end function vector3d_constructor

end module vector3d_module

program main
   use vector3d_module
   implicit none
   print *, vector3d_zero
end program main

 

Compiler version: ifort 2021.8.0 Build 20221119_000000

Labels (1)
1 Solution
Barbara_P_Intel
Employee
1,214 Views

I just tested this reproducer with the compiler that will be released in shortly. NO ICE!! Both ifort and ifx compile without errors.

I do get ICE with the current compiler, 2021.8.0, as reported.

 

View solution in original post

0 Kudos
5 Replies
andrew_4619
Honored Contributor III
1,288 Views

for the record The ICE is on the main program changing the interface name to "vector3d_type1" compiles OK.

Source1.f90
C:\Users\...\Console3\Source1.f90: internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
C:\Users\...\Console3\Source1.f90: catastrophic error: Internal Compiler Error: Ref module: ffe_param.c

 

Clearly an ICE is bug no argument. 

As an aside:

1] why have parameter vector3d_zero at all when you have default initialisation to zero in the type definition?

2] why try to redefine the defualt constructor why not use a modified name  for an alternative constructor?

 

0 Kudos
gzengm
Novice
1,279 Views

Thank you for your response, andrew_4619!

The initial code snippet I provided was just a minimal example to demonstrate the issue. However, here's a more practical version of the code that still encounters the same error:

module vector3d_module

   implicit none

   type :: vector3d_type
      real :: x = 0.0
      real :: y = 0.0
      real :: z = 0.0
   end type vector3d_type

   type :: vector2d_type
      real :: x = 0.0
      real :: y = 0.0
   end type vector2d_type

   type(vector3d_type), parameter :: vector3d_unitx = vector3d_type(1.0, 0.0, 0.0)

   interface vector3d_type
      module procedure vector3d_from_vector2d
   end interface

contains

   function vector3d_from_vector2d(vector2d) result(res)
      implicit none
      type(vector2d_type), intent(in) :: vector2d
      type(vector3d_type) :: res

      res%x = vector2d%x
      res%y = vector2d%y
      res%z = 0.0
   end function vector3d_from_vector2d

end module vector3d_module

program main

   use vector3d_module
   implicit none

   print *, vector3d_unitx

end program main
0 Kudos
gzengm
Novice
1,258 Views

In response to your question about using vector_zero while having default initialization to zero in the type definition, I believe that employing a predefined parameter, such as vector_zero, is a good practice. This approach ensures that we explicitly reference a clearly-defined constant, rather than relying on default initialization values. This can lead to more maintainable and understandable code, especially when working with larger or more complex projects.


@andrew_4619 wrote:

for the record The ICE is on the main program changing the interface name to "vector3d_type1" compiles OK.

Source1.f90
C:\Users\...\Console3\Source1.f90: internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
C:\Users\...\Console3\Source1.f90: catastrophic error: Internal Compiler Error: Ref module: ffe_param.c

 

Clearly an ICE is bug no argument. 

As an aside:

1] why have parameter vector3d_zero at all when you have default initialisation to zero in the type definition?

2] why try to redefine the defualt constructor why not use a modified name  for an alternative constructor?


 

0 Kudos
andrew_4619
Honored Contributor III
1,229 Views

Interestingly this compiles OK if you use 'last years' compiler rather than the latest so the ICE is a regression.

0 Kudos
Barbara_P_Intel
Employee
1,215 Views

I just tested this reproducer with the compiler that will be released in shortly. NO ICE!! Both ifort and ifx compile without errors.

I do get ICE with the current compiler, 2021.8.0, as reported.

 

0 Kudos
Reply