Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner

possible bug(???) in parameterized derived type bound procedures

Hi there.

the following code compiles and runs with 17.05 and 18.

Module Mod_A
  Type :: atype(k,lb1,ub1)
    Integer(kind=4), kind :: k
    integer(kind=8), len :: lb1=1,ub1
    integer(k) :: val(lb1:ub1)
  contains
    Generic :: bla => bla4, bla8
    Procedure, pass :: bla4 => SubBla4
    Procedure, pass :: bla8 => SubBla8
  End type atype
contains
  Subroutine SubBla8(this)
    Class(atype(8,lb1=*,ub1=*)), intent(inout) :: this
    write(*,*) "i am here ", this%val
  End Subroutine SubBla8
  Subroutine SubBla4(this)
    Class(atype(4,lb1=*,ub1=*)), intent(inout) :: this
    write(*,*) "i am here ", this%val
  End Subroutine SubBla4
End Module Mod_A
Program Test
  use Mod_A, only: atype
  Implicit none
  Type(atype(4,:,:)), allocatable :: xx
  allocate(atype(4,1,3)::xx)
  xx%val=(/1,2,3/)
  call xx%bla()
  call xx%bla8()
end Program Test

My intial guess would have been that "call xx%bla8()" should produce a compile time error  because the kind of xx is known at compile time as well as the kind in subroutine "SubBla8". the output is:

i am here            1           2           3
 i am here             8589934593                     3                     0

Thus, a small typo can ruin everything. The other way arround, initializing xx with 8 and calling bla4 works as well and produces the same non-sense. Is this a bug or am I getting something wrong???

Thanks

0 Kudos
1 Reply
Highlighted
Valued Contributor III

Quote:may.ka wrote:

may.ka wrote:

My intial guess would have been that "call xx%bla8()" should produce a compile time error .. Is this a bug or am I getting something wrong?

I think it is a bug in the Intel Fortran compiler, I suggest you submit an incident at the Intel OSC.

0 Kudos