Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27228 Discussions

Parameterized derived types: problem with inheritance and internal compiler error (C0000005)

SergeyL
Beginner
614 Views

Hello Intel Community, 

(1) I've got strange output with second order inheritance of PDT. Length parameter does not pass to second order child as it does to first order child. Simple code to reproduce it:

 

program Test
    type Type1(n)
        integer, len :: n
        integer :: a(n)
    end type Type1

    type, extends(Type1) :: Type2
    end type Type2

    type, extends(Type2) :: Type3
    end type Type3

    type(Type2(:)), allocatable :: test2
    type(Type3(:)), allocatable :: test3
   
    integer :: n = 10

    allocate(Type2(n) :: test2)
    allocate(Type3(n) :: test3)

    print *, test2%n, test3%n
end program Test

 

 

Output:

test2%n = 10, test3%n=825381445.

The second number changes from one run to another.

 

(2) I've got internal compiler error (C0000005) with PDT containing array which lower bound is negative and depends on length parameter. Code to reproduce:

 

module Test2

    type Array_Type(n)
        integer, len :: n
        real :: array(-n:n)
    contains 
        procedure :: InitArray
        procedure :: PrintArrayFrom1toN
    end type Array_Type

contains

    subroutine InitArray(self, new_array)
        class(Array_Type(*)), intent(inout) :: self
        real :: new_array(self%n)
        associate(array => self%array)
            array = new_array
        end associate
    end subroutine InitArray

    subroutine PrintArrayFrom1toN(self)
        class(Array_Type(*)), intent(in) :: self
        integer :: j
        do j = 1, self%n
           print *, self%array(j)
        end do
    end subroutine PrintArrayFrom1toN

end module Test2

 

 

Error arises when code has both associate block and negative indexes depending on length parameter. Compilation is successful if I replace associate block by equivalent statement self%array = new_array or if I change array range from -n:n to 1:n.

 

Compiler: Intel(R) Fortran 64 Compiler Classic, Version 2021.3.0 Build 20210609_000000, Windows 10.

0 Kudos
1 Solution
Devorah_H_Intel
Moderator
88 Views

The fix will be available in the next Intel Fortran Compiler release 2021.7

View solution in original post

7 Replies
FortranFan
Honored Contributor II
581 Views

@SergeyL ,

If your subscription allows, please submit a support request at:

https://supporttickets.intel.com/?lang=en-US

Otherwise, you can hope Intel staff picks it up from here.

I'm dismayed to witness such compiler issues, to say the least.  Particularly as I see value in the parameterized derived type (PDT) facility introduced in Fortran since 2003 and also had good use cases for it.  But I've submitted so many support incidents over the years but only to see the compiler continue to regress with other incidents that are only minor variants conceptually of incidents that I had already reported and which were reportedly fixed.

Good luck with your issue, hope it gets resolved soon.

SergeyL
Beginner
546 Views

Yes, PDTs are very useful for my applications since ranges of all arrays depend on a single length parameter. But I think I have to give up on using PDTs for now because of this inheritance problem.

Barbara_P_Intel
Moderator
498 Views

Good news! The internal compiler error (ICE) that you reported as the 2nd issue looks like it is fixed in the next release which is planned for this fall.


Barbara_P_Intel
Moderator
495 Views

Regarding the first issue you reported, I hate to be picky, but the output does not match the source you provided. The output shows the variable name.

Can you please confirm the source or the output?

Thank you!



SergeyL
Beginner
462 Views

The actual output is just two numbers without variable names: 10 825381445. The second number looks like random and changes from one run to another.

Yes, adding variable names to actual output doesn't provide a better explanation as i thought it would be.

Thanks for reply! Glad to hear good news about ICE.

Barbara_P_Intel
Moderator
445 Views

Thank you for clarifying. I filed CMPLRIL0-34123 on your behalf. I'll let you know its progress to a fix.



Devorah_H_Intel
Moderator
89 Views

The fix will be available in the next Intel Fortran Compiler release 2021.7

Reply