Compiler Bug: parameterized derived type - len parameter on argument passing

[Rodrigo_R_]

Hi,

I am observing some strange behaviour of Intel Compiler 18.0 Update 2 Intel(R) 64 on Windows 10 when trying to pass PDT's with len parameters to and from procedures.

Take this code sample:

module pdts
  implicit none

  type :: v(n)
    integer, len :: n
  end type

contains
  function op(v1, v2) result (v3)
    type(v(*)), intent(in) :: v1, v2
    type(v(v1%n * v2%n)) :: v3
    print *, "op(", v1%n, ", ", v2%n, ") ->", v3%n
  end
end

program test
  use :: pdts
  implicit none

  integer, parameter :: a = 6, b = 2
  type(v(a)) :: va = v(a)()
  type(v(b)) :: vb = v(b)()
  type(v(a * b)) :: vab
  type(v(99)) :: v99
  type(v(6)) :: v6

  print *, va%n, vb%n, vab%n, v99%n, v6%n  ! [1] output: 6, 2, 12, 99, 6
  vab = op(va, vb)                         ! [2] output: op(6, 2) -> 12
  vab = op(v(a)(), v(b)())                 ! [3] error #8747:
    ! All nondeferred type parameters in a structure constructor must have
    ! the same values as the corresponding type parameters of the object. 
  v99 = op(va, vb)                         ! [4] output: op(6, 2) -> 12
  v99 = op(v(a)(), v(b)())                 ! [5] error #8747:
  v6 = op(va, vb)                          ! [6] output: op(6, 2) -> 12
  v6 = op(v(a)(), v(b)())                  ! [7] output: op(0, 0) -> 12
  print *, va%n, vb%n, vab%n, v99%n, v6%n  ! [8] output: 6, 2, 12, 12, 12
end

The function op takes 2 PDT arguments with assumed len parameters and return a PDT with an automatic len parameter that is the multiplication of the other two.

In the tests, the outputs [1] and [2] show the correct, expected results.

Test [3] fails with error #8747, complaining about the len parameters not matching. I interpret this as a compiler bug, because if test[2] is valid then this should be valid too.

Test [4] doesn't throw any error, and I believe this is also a bug, because result's len parameter doesn't match the LHS of the assignment. More strangely, the assignment changes the len parameter of the variable, as you can see in output [8]. Test[5] breakes just like [3], but it was indeed supposed to fail in this case.

Test [6], just like [4], doesn't throw any error, when it should, and changes the len parameter of the variable.

But, surprisingly, test [7] doens't throw error #8747 like the others, and succeds in calling the procedure, although both argument's len parameters become zero. I noticed this only happens when the len parameter of the first passed argument match the len parameter of the PDT in the LHS of the assignment. This is also a bug, because it mismatches the result's declaration in the function.

Are my observations valid or am I missing something in this example?

[Mark_Lewy]

The only comment I have is that is the program standard conforming by having a PDT with no compenent-part?

It compiles and works if you add a single real :: v(n) component and modify the structure constructors appropriately.

[Steve_Lionel]

Mark Lewy wrote:

The only comment I have is that is the program standard conforming by having a PDT with no compenent-part?

Yes, it is conforming. One is not required to have components in any derived type.

[Rodrigo_R_]

So, it is a bug? Should I open a ticket for it?

[Steve_Lionel · Accepted solution]

Yes, you should. But first try it with the 19.0 release. (I tried the beta and it still fails - I don't have the release installed yet.