Nvfortran bug: two different-named entities are mixed up

In the program below, the entities nona (scalar dummy argument) and nona2 (external procedure) are mixed up and a bogus error is issued:

$ nvfortran -c a.f90
NVFORTRAN-S-0134-Illegal attribute - intent specified for dummy subprogram argument nona (a.f90: 12)
  0 inform,   0 warnings,   1 severes, 0 fatal for test

The error is bogus because nona was never declared as a subprogram (nona2 is), and it goes away if procedure(foo) is changed to external, or if nona2 is renamed to nona_2 or nona2a.

module bah

abstract interface
  subroutine foo()
  end subroutine foo
end interface

end module bah

subroutine test(nona)

logical, intent(in) :: nona

procedure(foo) :: nona2

write(6,*) nona
call nona2()

end subroutine test
$ nvfortran --version

nvfortran 20.9-0 LLVM 64-bit target on x86-64 Linux -tp sandybridge 
NVIDIA Compilers and Tools
Copyright (c) 2020, NVIDIA CORPORATION.  All rights reserved.

Thanks Jellby. I was able to recreate the error here and have filed a problem report, TPR #32373.

Besides make it external, another work around is to add a specific interface. Something like:

module bah

abstract interface

subroutine foo()

end subroutine foo

end interface

end module bah

subroutine test(nona)

use bah

logical, intent(in) :: nona

interface

subroutine nona2()

end subroutine

end interface

write(6,*) nona

call nona2()

end subroutine test

-Mat

Yeah, well… Using procedure(foo) was a way to avoid having to write an explicit interface (especially when there are many subroutines that share the same one).

By the way, I just realized I was missing the use bah part, although the error is the same. Make it like this:

module bah

abstract interface
  subroutine foo()
  end subroutine foo
end interface

end module bah

subroutine test(nona)

implicit none
use bah, only: foo
logical, intent(in) :: nona

procedure(foo) :: nona2

write(6,*) nona
call nona2()

end subroutine test

Now the other question (bug?) is why does it work (after renaming nona2) without using the module?

No idea, but our compiler engineers will investigate.