PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Could not resolve generic procedure

 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling
View previous topic :: View next topic  
Author Message
helvio



Joined: 24 Jul 2012
Posts: 7

PostPosted: Wed Aug 01, 2012 11:06 pm    Post subject: Could not resolve generic procedure Reply with quote

Hi,

I have an issue with the compilation of my code related with the resolution of generic interfaces. I cannot post my code due to its large extent, but I isolated the origin of the problem and I pasted a simple example below. I apologize for the length of the code. I signaled the most important lines with commented out labelled arrows:

Code:
MODULE su2_matrix

   IMPLICIT NONE

   PRIVATE
   PUBLIC :: su2, trace

   TYPE :: su2
      COMPLEX :: a = CMPLX(1.,0.) ! <=== [1]
      COMPLEX :: b = CMPLX(0.,0.) ! <=== [2]
   END TYPE su2

   INTERFACE trace
      MODULE PROCEDURE tr_su2
   END INTERFACE trace

CONTAINS

   PURE ELEMENTAL FUNCTION tr_su2(u) RESULT(z)
      TYPE(su2), INTENT(in) :: u
      COMPLEX :: z
      z = CMPLX(2.*REAL(u%a),0.)
   END FUNCTION tr_su2

END MODULE su2_matrix


MODULE suN_matrix

   USE su2_matrix ! <=== [3]

   IMPLICIT NONE

   PRIVATE
   PUBLIC :: suN, trace

   INTEGER, PARAMETER, PRIVATE :: N = 3

   TYPE :: suN
      COMPLEX :: idx(N,N)
   END TYPE suN

   INTERFACE trace
      MODULE PROCEDURE tr_suN
   END INTERFACE trace

CONTAINS

   PURE ELEMENTAL FUNCTION tr_suN(a) RESULT(z)
      TYPE(suN), INTENT(in) :: a
      COMPLEX :: z
      INTEGER :: i
      z = CMPLX(0.,0.)
      DO i=1,N
         z = z + a%idx(i,i)
      END DO
   END FUNCTION tr_suN

END MODULE suN_matrix


MODULE dof

   USE suN_matrix ! <=== [4]
   USE su2_matrix ! <=== [5]

   IMPLICIT NONE

   PRIVATE
   PUBLIC :: su2, suN, trace

END MODULE dof


MODULE lattfield

   USE dof          ! <=== [6]
   !USE suN_matrix  ! <=== [7]
   !USE su2_matrix  ! <=== [8]

   IMPLICIT NONE

   PRIVATE
   PUBLIC :: cpx_field, su2_field, suN_field, trace

   INTEGER, PARAMETER :: l(3) = [ 8,8,8 ]

   TYPE :: cpx_field
      COMPLEX :: site(l(1),l(2),l(3))
   END TYPE cpx_field

   TYPE :: su2_field
      TYPE(su2) :: site(l(1),l(2),l(3))
   END TYPE su2_field

   TYPE :: suN_field
      TYPE(suN) :: site(l(1),l(2),l(3))
   END TYPE suN_field

   INTERFACE trace
      MODULE PROCEDURE tr_su2f
      MODULE PROCEDURE tr_suNf
   END INTERFACE trace

CONTAINS

   PURE ELEMENTAL FUNCTION tr_su2f(a) RESULT(z)
      TYPE(su2_field), INTENT(in) :: a
      TYPE(cpx_field) :: z
      z%site = trace(a%site)
   END FUNCTION tr_su2f

   PURE ELEMENTAL FUNCTION tr_suNf(a) RESULT(z)
      TYPE(suN_field), INTENT(in) :: a
      TYPE(cpx_field) :: z
      z%site = trace(a%site) ! <=== [9]
   END FUNCTION tr_suNf

END MODULE lattfield


The code contains 4 modules, the 3rd of which, "MODULE dof", is an umbrella module that I use for pure convenience. All it does is to collect the public objects in the 1st and 2nd modules and make them public again, so I can use them in "MODULE lattfield".

In principle, there is nothing wrong in doing this that I know of. In fact, it compiles and behaves perfectly well with the Intel and GNU compilers. However, when I compile it with pgf90 (PGI Workstation v12.5 for Linux) it issues the following error, associated with line [9]:

Quote:
PGF90-S-0155-Could not resolve generic procedure trace (test.f90: 119)
0 inform, 0 warnings, 1 severes, 0 fatal for tr_sunf


The error message vanishes and the compilation is successful in any of the following situations:


    1) if I swap the lines labelled by [4] and [5] like this:
    Code:
       USE su2_matrix ! <=== [5]
       USE suN_matrix ! <=== [4]


    2) if I simply avoid calling "USE dof" in the last module, line [6], and call the 1st and 2nd modules directly, lines [7] and [8].

    3) if I delete the line [3] (but it should be there for future use).

    4) and also, curiously, if I avoid instantiating the components of the derived type "su2" with default values, in lines [1] and [2] (This one is puzzling).


Thus the question is: Why is this so? Why can't I use an umbrella module in this way? Why is the order of the lines [4] and [5] important? I don't remember the order being relevant in the Fortran standard. Also, the derived types "su2" and "suN" are very different and there is no apparent ambiguity in the generic interface for "trace".

Thank you,
helvio

Update: I made corrections to the code above.
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5952
Location: The Portland Group Inc.

PostPosted: Thu Aug 02, 2012 2:41 pm    Post subject: Reply with quote

Hi Helvio,

Thanks again for putting together these great examples. I showed the problem to several of our compiler engineers who confirmed that this problem is related to another issue (TPR#17633) which should be fixed in 12.8. However, your problem is sightly different, hence I created a new problem report (TPR#18856). Hopefully, we have this fixed in 12.8 as well or soon after.

Best Regards,
Mat
Back to top
View user's profile
helvio



Joined: 24 Jul 2012
Posts: 7

PostPosted: Sun Aug 05, 2012 10:07 am    Post subject: Reply with quote

You're welcome.

Meanwhile I just faced another compilation problem related with a similar but different issue, so I decided not to open a new topic. Again, the following code compiles well with other compilers, but not with PGI's, and the problem is again the use of what I call an "umbrella module", an intermediate module that aggregates and pipelines the PUBLIC objects from other modules.

Code:
MODULE su2mat

   IMPLICIT NONE

   PRIVATE
   PUBLIC :: su2

   TYPE :: su2
      COMPLEX :: a = 1.
      COMPLEX :: b = 0.
   END TYPE su2

   INTERFACE su2
      MODULE PROCEDURE ctor_su2
   END INTERFACE su2

CONTAINS

   PURE ELEMENTAL FUNCTION ctor_su2(a0) RESULT(u)
      REAL, INTENT(in) :: a0
      TYPE(su2) :: u
      u%a = a0
      u%b = 0.
   END FUNCTION ctor_su2

END MODULE su2mat


MODULE umbrella

   USE su2mat

   PUBLIC :: su2

END MODULE umbrella


MODULE matrixf

   USE umbrella  ! <== [1]
   !USE su2mat   ! <== [2]

   IMPLICIT NONE

   TYPE :: scalar_field
      REAL, ALLOCATABLE :: site(:,:,:)  ! <== [3]
   END TYPE scalar_field

   TYPE :: matrix_field
      TYPE(su2), ALLOCATABLE :: site(:,:,:)  ! <== [4]
   END TYPE matrix_field

   INTERFACE ASSIGNMENT(=)
      MODULE PROCEDURE eq_m_s
   END INTERFACE ASSIGNMENT(=)

CONTAINS

   PURE ELEMENTAL SUBROUTINE eq_m_s(A, z)
      TYPE(matrix_field), INTENT(out) :: A
      TYPE(scalar_field), INTENT(in)  :: z
      A%site = su2(z%site)
   END SUBROUTINE eq_m_s

END MODULE matrixf


In the 1st module "su2mat" I define the derived type "su2" and its structure constructor, which is ELEMENTAL. Then, I pipeline "su2" through the 2nd module. Finally, I use "su2" it in the 3rd module to construct new derived types, "scalar_field" and "matrix_field", and an overloaded assignment between them (which is ELEMENTAL too, but that isn't relevant here); in the last module I may use "su2" by calling either "su2mat" or "umbrella".

If I USE "su2mat", the code compiles successfully. If I USE "umbrella" instead (which is what I really need to do), the compiler issues error messages. Curiously enough, those error messages depend on the nature of the components of the "scalar_field" and "matrix_field" derived types:

    1) If the components are ALLOCATABLE and rank 1 to 3, or if the components are not ALLOCATABLE and are declared with explicit bounds, the compiler issues the error:
    Quote:
    PGF90-F-0000-Internal compiler error. search_arr: not TY_ARRAY 29 (mod.f90: 62)
    PGF90/x86-64 Linux 12.5-0: compilation aborted


    2) If the components are ALLOCATABLE and rank 4, the compiler issues the error:
    Quote:
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 628 (mod.f90: 62)
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 628 (mod.f90: 62)
    PGF90-F-0000-Internal compiler error. search_arr: not TY_ARRAY 135 (mod.f90: 62)
    PGF90/x86-64 Linux 12.5-0: compilation aborted


    3) If the components are ALLOCATABLE and rank 5, the compiler issues the error:
    Quote:
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 633 (mod.f90: 62)
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 633 (mod.f90: 62)
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 633 (mod.f90: 62)
    PGF90-S-0000-Internal compiler error. check_member: member arrived with wrong derived type 633 (mod.f90: 62)
    PGF90-F-0000-Internal compiler error. search_arr: not TY_ARRAY 160 (mod.f90: 62)
    PGF90/x86-64 Linux 12.5-0: compilation aborted



and so on, with 2 repeated error messages per extra semicolon.

Is this another bug of the compiler? It is a bit frustrating that I cannot use the umbrella module as an intermediate module in many cases. Or is it a problem in my code? I don't remember if structure constructors are forbidden to be ELEMENTAL, but it doesn't seem to be the problem here.

Thanks again,
helvio
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5952
Location: The Portland Group Inc.

PostPosted: Mon Aug 06, 2012 10:08 am    Post subject: Reply with quote

Hi Helvio,

Quote:
Is this another bug of the compiler?
It looks to me to be a different symptom of the same problem as before. I've passed this one on as well (TPR#18862).

- Mat
Back to top
View user's profile
jtull



Joined: 30 Jun 2004
Posts: 395

PostPosted: Tue May 21, 2013 6:48 pm    Post subject: TPR 18856 is fixed. Reply with quote

TPR 18856 - Could not resolve generic procedure trace
was corrected in the 13.1 release .

thanks,
dave
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © phpBB Group