More problems with paramterized derived types

Andrew_Smith · ‎11-27-2014

This code gives compile errors which I would like help to fix:

module Bar
   implicit none
   integer, parameter :: DP = selected_real_kind(13)

   type VarA(k, n)
      integer, kind :: k
      integer, len :: n
      real(k) :: v
      real(k) :: d(n)
   end type
   
   interface assignment(=)
      module procedure ass_pair
   end interface
   
   contains
   
   pure subroutine ass_pair(b, a)
      type(VarA(DP,*)), intent(in) :: a
      type(VarA(DP,a%n)), intent(inout) :: b
      b%v = a%v
      b%d = a%d
   end subroutine

   pure function max_pair(a, b) result(c)
      type(VarA(DP,*)), intent(in) :: a
      type(VarA(DP,a%n)), intent(in) :: b
      type(VarA(DP,a%n)) c
      
      if (a%v > b%v) then
         c = a
      else
         c = b
      end if
   end function
   
   pure function maxval_array(a) result(b)
      type(VarA(DP,*)), intent(in) :: a(:)
      type(VarA(DP,a%n)) b
      integer i
      b = a(1)
      do i = 2, size(a)
         b = max_pair(a(i), b)
      end do
   end function
   
end module

Source1.f90(31): error #8745: All nondeferred nonassumed type parameters of the dummy argument must have the same values as the corresponding type parameters of the actual argument.
         c = a
---------^
Source1.f90(33): error #8745: All nondeferred nonassumed type parameters of the dummy argument must have the same values as the corresponding type parameters of the actual argument.
         c = b
---------^
Source1.f90(41): error #8745: All nondeferred nonassumed type parameters of the dummy argument must have the same values as the corresponding type parameters of the actual argument.
      b = a(1)
------^
Source1.f90(43): error #8745: All nondeferred nonassumed type parameters of the dummy argument must have the same values as the corresponding type parameters of the actual argument.
         b = max_pair(a(i), b)
----------------------------^
Source1.f90(43): error #8745: All nondeferred nonassumed type parameters of the dummy argument must have the same values as the corresponding type parameters of the actual argument.
         b = max_pair(a(i), b)
---------^

This code variant causes internal compiler error but none of the previous errors:

module Bar
   implicit none
   integer, parameter :: DP = selected_real_kind(13)

   type VarA(k, n)
      integer, kind :: k
      integer, len :: n
      real(k) :: v
      real(k) :: d(n)
   end type
   
   interface assignment(=)
      module procedure ass_pair
   end interface
   
   contains
   
   pure subroutine ass_pair(b, a)
      type(VarA(DP,*)), intent(in) :: a
      type(VarA(DP,*)), intent(inout) :: b
      b%v = a%v
      b%d = a%d
   end subroutine

   pure function max_pair(a, b) result(c)
      type(VarA(DP,*)), intent(in) :: a
      type(VarA(DP,*)), intent(in) :: b
      type(VarA(DP,a%n)) c
      
      if (a%v > b%v) then
         c = a
      else
         c = b
      end if
   end function
   
   pure function maxval_array(a) result(b)
      type(VarA(DP,*)), intent(in) :: a(:)
      type(VarA(DP,a%n)) b
      integer i
      b = a(1)
      do i = 2, size(a)
         b = max_pair(a(i), b)
      end do
   end function
   
end module

Yuan_C_Intel · ‎11-28-2014

Hi, Andrew

Which compiler version you are using?

I cannot reproduce the internal error with latest compiler 15.0.1:

$ cat p_derivedT.f90
module Bar
implicit none
integer, parameter :: DP = selected_real_kind(13)

type VarA(k, n)
integer, kind :: k
integer, len :: n
real(k) :: v
real(k) :: d(n)
end type

interface assignment(=)
module procedure ass_pair
end interface

contains

pure subroutine ass_pair(b, a)
type(VarA(DP,*)), intent(in) :: a
type(VarA(DP,*)), intent(inout) :: b
b%v = a%v
b%d = a%d
end subroutine

pure function max_pair(a, b) result(c)
type(VarA(DP,*)), intent(in) :: a
type(VarA(DP,*)), intent(in) :: b
type(VarA(DP,a%n)) c

if (a%v > b%v) then
c = a
else
c = b
end if
end function

pure function maxval_array(a) result(b)
type(VarA(DP,*)), intent(in) :: a(:)
type(VarA(DP,a%n)) b
integer i
b = a(1)
do i = 2, size(a)
b = max_pair(a(i), b)
end do
end function

end module

$ ifort -c -V p_derivedT.f90
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

Intel(R) Fortran 15.0-1750

Please note that we just started to support parameterized derived type in 15.0.

Thanks

Andrew_Smith · ‎11-28-2014

I am using windows XE 15.0.1.148, looks like you used Linux version.

Yuan_C_Intel · ‎12-08-2014

Hi, Andrew

I still cannot reproduce the error on Windows.

Did you use any special options for compilation?

The second case still works for me on both Windows and Linux. Only the first code will get the expected compiler errors.

c:\\issues\U536542>ifort -c paraDT1.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte
l(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

paraDT1.f90(31): error #8745: All nondeferred nonassumed type parameters of the
dummy argument must have the same values as the corresponding type parameters of
the actual argument.
c = a
---------^
paraDT1.f90(33): error #8745: All nondeferred nonassumed type parameters of the
dummy argument must have the same values as the corresponding type parameters of
the actual argument.
c = b
---------^
paraDT1.f90(41): error #8745: All nondeferred nonassumed type parameters of the
dummy argument must have the same values as the corresponding type parameters of
the actual argument.
b = a(1)
------^
paraDT1.f90(43): error #8745: All nondeferred nonassumed type parameters of the
dummy argument must have the same values as the corresponding type parameters of
the actual argument.
b = max_pair(a(i), b)
----------------------------^
paraDT1.f90(43): error #8745: All nondeferred nonassumed type parameters of the
dummy argument must have the same values as the corresponding type parameters of
the actual argument.
b = max_pair(a(i), b)
---------^
compilation aborted for paraDT1.f90 (code 1)

c:\issues\U536542>ifort -c paraDT2.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte
l(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

Thanks.

FortranFan · ‎12-10-2014

Yolanda Chen (Intel) wrote:

..

I still cannot reproduce the error on Windows.

Did you use any special options for compilation?

The second case still works for me on both Windows and Linux. Only the first code will get the expected compiler errors.

c:\\issues\U536542>ifort -c paraDT1.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte
l(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

..

Yolanda,

Try the 32-bit (IA-32) compiler version. I too do not get the error with 64-bit compilation, but I get with the IA-32 version:

------ Build started: Project: TestFor, Configuration: Debug|Win32 ------

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.1.148 [IA-32]...
bar.f90
C:\..\bar.f90(20): warning #7026: Non-standard extension.   [VARA#8&*]
C:\..\bar.f90(26): warning #7026: Non-standard extension.   [VARA#8&*]
C:\..\bar.f90(27): warning #7026: Non-standard extension.   [VARA#8&*]
C:\..\bar.f90(38): warning #7026: Non-standard extension.   [VARA#8&*]
fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for C:\..\bar.f90 (code 1)

Build log written to  "file://C:\..\TestForBuildLog.htm"
TestFor - 1 error(s), 4 warning(s)

Yuan_C_Intel · ‎12-24-2014

Hi, FortranFan

Thank you for reminding me IA-32 version. Yes, I have reproduced the internal error now with IA-32 compiler.

Hi, Andrew

I have reproduced your issue and entered it in our problem tracking system. We will try to resolve this issue as soon as we can. However, please be advised that this issue may have to be targeted to for the next major release. I will let you know when I have an update on this issue.

Thank you.

Yuan_C_Intel · ‎12-29-2014

Hi, Andrew

I have filed internal ticket DPD200364803 to track the issue.

Thank you.