topic Thanks for that Steve. It is in Intel® Fortran Compiler

Compiler errors with parameterized types using defined assignment and - operator

Andrew_Smith — Wed, 06 May 2015 21:40:50 GMT

module TestParamTypeMod
   integer, parameter :: DP =  SELECTED_REAL_KIND(13)
   
   type DoubleDif(n)
      integer, len :: n
      real(DP) :: v
      real(DP) :: d(n)
   end type
   
   interface assignment(=)
      module procedure ass_D_Dpdif, ass_Dpdif_Dpdif
   end interface
   
   interface operator(-)
      module procedure sub_Dpdif_Dpdif
   end interface
   
contains

pure elemental subroutine ass_D_Dpdif(b, a)
   real(DP), intent(in) :: a
   type(DoubleDif(*)), intent(inout) :: b
   b%v = a
   b%d = 0.0_DP
end subroutine

pure subroutine ass_Dpdif_Dpdif(b, a)
   type(DoubleDif(*)), intent(inout) :: b
   type(DoubleDif(*)), intent(in) :: a
   b%v = a%v
   b%d = a%d
end subroutine

pure function sub_Dpdif_Dpdif(a, b) result(c)
   type(DoubleDif(*)), intent(in) :: a
   type(DoubleDif(*)), intent(in) :: b
   type(DoubleDif(a%n)) c
   c%v = a%v - b%v
   c%d = a%d - b%d
end function

end module

program Test
   use TestParamTypeMod
   type(DoubleDif(1)) a, b, c
   
   a = 2.0_DP
   b = 1.0_DP
   b%d = 3.0_DP
   call ass_Dpdif_Dpdif(c, b - a)
   c = b - a
   print *, c%v, c%d
end program

This gives errors:

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.3.208 [Intel(R) 64]...
TestParamType.f90
D:\dev\TestParamType.f90(51): error #6633: The type of the actual argument differs from the type of the dummy argument.
D:\dev\TestParamType.f90(52): error #6197: An assignment of different structure types is invalid.
ifort: error #10298: problem during post processing of parallel object compilation
compilation aborted for D:\dev\TestParamType.f90 (code 1)

Is my code f2008 compliant and / or is it compiler errors ?

I'll look into this and see

Steven_L_Intel1 — Thu, 07 May 2015 00:24:23 GMT

I'll look into this and see what's up. This sounds vaguely familiar....

Yes, it is familiar because

Steven_L_Intel1 — Thu, 07 May 2015 19:47:20 GMT

Yes, it is familiar because this question got asked not too long ago.

The problem here is the result type of sub_Dpdif_Dpdif, which is DoubleDif(a%n) where a is one of the dummy arguments. This is a specification expression, which is fine as it is, but our compiler thinks it isn't "consistent" with a dummy argument that has an assumed length parameter. I have a feeling that the compiler is not correct here, but am having trouble finding words to say so. I have asked other standards committee members for advice and will let you know what comes out of this.

Thanks for that Steve. It is

Andrew_Smith — Fri, 08 May 2015 07:20:50 GMT

Thanks for that Steve. It is good to have recognition that something may be awry in the standard rather than a bad implementation.

On line 39 of my code where I do a vector subtract, does the compiler know that the two vectors are the same size ? Is it able to optimize the vector operation without this information ? Did the standards committee anticipate this problem?

If it is OK for the declaration of a return value or local variable to reference the length of a dummy argument (and I see no other way to declare them), then why can't dummy arguments do the same so that b could reference a and only a would have assumed length. The compiler needs to recognize the chain of "assumedness" for both these cases. In cases where arguments have matched lengths then the compiler should also check that actual arguments do have matching lengths.

From what my fellow standards

Steven_L_Intel1 — Fri, 08 May 2015 18:14:00 GMT

From what my fellow standards people tell me, your code is correct and should work. I will report this as a bug to our developers. Issue ID is DPD200370162.

We assume that the shapes match, as required by the standard, so I would expect vectorization if the compiler thinks it profitable. You can turn on optimization reports and see what it says.

Hi Steve and Andrew,

Wukie__Nathan — Mon, 18 May 2015 23:42:44 GMT

Hi Steve and Andrew,

I am working on what appears to be the same application presented here and happened upon the same error.

error #6197: An assignment of different structure types is invalid.

Are either of you aware of a work around for this issue? Maybe a different definition for the overloaded operator that would better inform the compiler for the time being?

There is no workaround

Andrew_Smith — Tue, 19 May 2015 11:58:04 GMT

There is no workaround

It may not be the same

Steven_L_Intel1 — Fri, 29 May 2015 13:27:30 GMT

It may not be the same problem, even if the diagnostic is the same. Can you provide us with a small test case?

Andrew's issue is expected to

Steven_L_Intel1 — Thu, 05 Nov 2015 16:38:02 GMT

Andrew's issue is expected to be fixed in 16.0.1 (2016 Update 1).