pgfortran 14.3 bug

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

Hi rohou,

I am checking around internally about this issue. I will follow up with more information soon.

Best regards,

+chris

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

Rohou,

This is indeed a bug - a report has been filed, and it is being investigated by our developers.

I’m checking on the issues Sean reported to see if they are related.

Thanks for all the great feedback!

Best regards,

+chris

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):

[dh045218:polygone/v4.1/pgi_bug] ianthompson% pgfortran -V

pgfortran 14.3-0 64-bit target on Apple OS/X developer $INFOTPVAL
The Portland Group - PGI Compilers and Tools
Copyright © 2014, NVIDIA CORPORATION. All rights reserved.
[dh045218:polygone/v4.1/pgi_bug] ianthompson% pgfortran -c mod_bug.f90
PGF90-S-0155-PASS argument must be declared CLASS in destroy (mod_bug.f90: 75)
PGF90-S-0155-PASS argument must be scalar, nonpointer, and nonallocatable in destroy (mod_bug.f90: 75)
PGF90/x86-64 OSX 14.3-0: compilation completed with severe errors

Hi Ian,

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.

Best regards,

+chris

I’m wondering whether a fix for this is in the works/released - do you have an issue number perhaps?

Hi Rohou,

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.

Best regards,

+chris

Sean:

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.

Best regards,

+chris


Ian:

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.

Best regards,

+chris


TPR 20313 - "UF: Invalid error msg on type bound proc with same name as proc in different module "

has been corrected in the current 14.6 release.

Thanks again for the original report.

regards,
dave

While the exact behavior reported in the OP may have been fixed, 14.6 still has problems with procedure names. See https://forums.developer.nvidia.com/t/pgfortran-14-6-bug-stuck-in-endless-loop/134138/1

TPR 20565 - UF: Invalid error msg with Fortran Generic Procedures

which appears to be one of multiple TPRs associated with this User Forum entry, has been fixed in the 14.7 release.


thanks,
dave

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.


thanks,
dave