|
| View previous topic :: View next topic |
| Author |
Message |
helvio
Joined: 24 Jul 2012
Posts: 7
|
 Posted: Wed Aug 01, 2012 11:06 pm Post subject: Could not resolve generic procedure |
 |
|
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 |
|
 |
mkcolg
Joined: 30 Jun 2004
Posts: 4996
Location: The Portland Group Inc.
|
| Posted: Thu Aug 02, 2012 2:41 pm Post subject: |
|
|
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 |
|
|
helvio
Joined: 24 Jul 2012
Posts: 7
|
| Posted: Sun Aug 05, 2012 10:07 am Post subject: |
|
|
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 |
|
|
mkcolg
Joined: 30 Jun 2004
Posts: 4996
Location: The Portland Group Inc.
|
| Posted: Mon Aug 06, 2012 10:08 am Post subject: |
|
|
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 |
|
|
jtull
Joined: 30 Jun 2004
Posts: 234
|
| Posted: Tue May 21, 2013 6:48 pm Post subject: TPR 18856 is fixed. |
|
|
TPR 18856 - Could not resolve generic procedure trace
was corrected in the 13.1 release .
thanks,
dave |
|
| Back to top |
|
|
|
|
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 © 2001, 2002 phpBB Group
|
Search
Memberlist
Register
Profile
Log in
