The code below confuses pgfortran because several subprograms share the same names. Other compilers (NAG, Intel) have no trouble with it:
module ImageHeaders
type :: ImageHeader
end type ImageHeader
contains
pure logical function IsAllocated(self)
class(ImageHeader), intent(in) :: self
end function
subroutine PrintInfo(self)
class(ImageHeader), intent(in) :: self
end subroutine PrintInfo
end module ImageHeaders
module ImageFiles
use ImageHeaders
type ImageFile
end type ImageFile
end module ImageFiles
module ImagesCore
type Image
contains
procedure :: PrintInfo
procedure :: IsAllocated
procedure :: AssignComplexToImage
generic :: assignment(=) => AssignComplexToImage
end type Image
contains
subroutine ReadFromImageFile(self,my_imagefile)
use ImageFiles
class(Image), intent(inout) :: self
type(ImageFile), intent(inout) :: my_imagefile
end subroutine ReadFromImageFile
pure logical function IsAllocated(self)
class(Image), intent(in) :: self
end function IsAllocated
subroutine PrintInfo(self)
class(Image), intent(in) :: self
end subroutine PrintInfo
subroutine AssignComplexToImage(self,complex_value)
class(Image), intent(inout) :: self
complex, intent(in) :: complex_value
end subroutine AssignComplexToImage
end module ImagesCore
Hmm. I have two similar cases where PGI rejects code where an interface block defines a generic function with the name of an external. I’m not positive whether or not they are related, though, since unlike the OP they are only present when the used modules are private.
This first case has an error that goes away if you add an “only” clause to a use statement.
module foo_mod
implicit none
private
interface foo
integer function foo()
end function foo
end interface
public :: foo
end module foo_mod
module bar_mod
use foo_mod
! use foo_mod, only: foo ! Uncommenting this line fixes the error.
implicit none
contains
subroutine bar
integer :: ithr
ithr=foo()
end subroutine bar
end module bar_mod
The next problem goes away if you swap the order of the “middle_mod” and “foo_mod” use statements, even though “middle_mod” doesn’t provide any public entities.
This is interesting in and of itself, because we seem to run into an issue every few months where PGI requires the order of use statements to be swapped, but this is the first time we’ve been able to isolate a manageable test case.
module foo_mod
implicit none
private
interface foo
integer function foo()
end function foo
end interface
public :: foo
end module foo_mod
module middle_mod
use foo_mod, only: foo
implicit none
private
end module middle_mod
module bar_mod
! Commenting the middle_mod use, or moving it down, fixes the error.
use middle_mod
use foo_mod, only: foo
implicit none
contains
subroutine bar
integer :: ithr
ithr=foo()
end subroutine bar
end module bar_mod
This seems to be similar to the cases reported above. In particular, renaming destroy in second_mod eliminates the problem (as do other apparently inconsequential changes).
module first_mod
implicit none
private
public :: my_type
!-----
type :: my_type
end type
!-----
contains
!-----
subroutine destroy( t )
type (my_type) , intent (inout) , pointer :: t
end subroutine
!-----
end module
!*****
module second_mod
implicit none
private
public :: another_type
!-----
type :: another_type
contains
procedure , pass :: destroy
end type
!-----
contains
!-----
subroutine output( t )
use first_mod , only : my_type
type (my_type) , intent (in) :: t
end subroutine
!-----
subroutine destroy( a )
class (another_type) , intent (inout) :: a
end subroutine
!-----
end module
Using Free PGI under OS X 10.7.5 (with XCode 4.6.3):
I was able to reproduce the issue as you mentioned it in the other thread, and our developers are currently looking into it. Will update you as we have more news.
Apologies for the missed communication. I am relatively new at helping out with the user forum, and have been learning some best practices as I go.
The issue you originally reported appears to be fixed as of the 14.6 release:
cparrott@galaxy ~/UF/bug $ cat ImagesCore.f90
module ImageHeaders
type :: ImageHeader
end type ImageHeader
contains
pure logical function IsAllocated(self)
class(ImageHeader), intent(in) :: self
end function
subroutine PrintInfo(self)
class(ImageHeader), intent(in) :: self
end subroutine PrintInfo
end module ImageHeaders
module ImageFiles
use ImageHeaders
type ImageFile
end type ImageFile
end module ImageFiles
module ImagesCore
type Image
contains
procedure :: PrintInfo
procedure :: IsAllocated
procedure :: AssignComplexToImage
generic :: assignment(=) => AssignComplexToImage
end type Image
contains
subroutine ReadFromImageFile(self,my_imagefile)
use ImageFiles
class(Image), intent(inout) :: self
type(ImageFile), intent(inout) :: my_imagefile
end subroutine ReadFromImageFile
pure logical function IsAllocated(self)
class(Image), intent(in) :: self
end function IsAllocated
subroutine PrintInfo(self)
class(Image), intent(in) :: self
end subroutine PrintInfo
subroutine AssignComplexToImage(self,complex_value)
class(Image), intent(inout) :: self
complex, intent(in) :: complex_value
end subroutine AssignComplexToImage
end module ImagesCore
cparrott@galaxy ~/UF/bug $ pgfortran -c ImagesCore.f90
cparrott@galaxy ~/UF/bug $ pgfortran -V
pgfortran 14.6-0 64-bit target on x86-64 Linux -tp sandybridge
The Portland Group - PGI Compilers and Tools
Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
The additional issues raised by others in this thread are being investigated, and we hope to have a resolution soon. I will follow up here with TPR numbers as I can locate them.
The two problems you reported here are currently logged as TPR #20565 and TPR #20566. They are being actively investigated by our developers at this time, and we will notify you as soon as a fix is available.
We have determined that this issue is actually different than the issues posted by others earlier in this thread. This issue has been logged as TPR #20574, and is currently under active investigation by our developers. We will notify you as soon as a fix is available.
TPR 20574 - UF: invalid error message with overloaded tbp procedure-name (F2003) which appears to be one of multiple TPRs associated with this User Forum entry, has been fixed in the 14.7 release.