Showing results for 
Search instead for 
Did you mean: 

Inconsistent acceptance of parameterised derived type parameter in procedure declarations

It looks like there's something off with using a length parameter from a parameterised derived type arguement in a procedure. In the following, do_a fails to compile ("This component is not a field of the encompassing structure.") while do_b works - even though they're identical. Perhaps worse, it accepts x(n) for do_a, even though n isn't defined anywhere and implicit none is in effect. Attempting to use this (e.g. x = 1.0) generates an ICE.

module test_module

  implicit none

  type :: a(n)
     integer, len :: n
     procedure :: do_a
     procedure :: do_b
  end type a


  subroutine do_a ( this, x )

    class(a(n=*)), intent(in) :: this
    !real, intent(out) :: x(this%n) ! <--- this fails
    !real, intent(out) :: x(n) ! <--- this works, but causes ICE when referenced
    real, intent(out) :: x(*)

    x(1:this%n) = 1.0 ! <--- generates ICE if x(n) used above

  end subroutine do_a

  subroutine do_b ( this, x )

    class(a(n=*)), intent(in) :: this
    real, intent(out) :: x(this%n) ! <--- this works (!)

    x(1:this%n) = 1.0 ! <--- no ICE from this one

  end subroutine do_b

end module test_module

Here's the ICE:

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
test.f90(19): 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.


0 Kudos
1 Reply

Thanks, we'll check it out.

Thanks, we'll check it out.

Retired 12/31/2016
0 Kudos