[Bug fortran/108850] New: SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[Bug fortran/108850] New: SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[johnww at tds dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850

            Bug ID: 108850
           Summary: SELECT CASE within BLOCK construct in one subroutine
                    prevents compilation of another subroutine named
                    "SELECT"
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: johnww at tds dot net
  Target Milestone: ---

Created attachment 54489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54489&action=edit
Output from "gfortran -v -save-temps -c select_within_block.f90"

Verbose compilation output is in the attachment.

With gfortran 10.2.1 (as I found earlier with 4.9.2) the following code fails
to compile:

module m
   implicit none
   private

   public :: a, select

contains

   subroutine a(x)
      integer, intent(in)  :: x
      !  cut down from named block construct with exits
      block
         select case (x)
         case (1)
            ! ...
         case (2)
            ! ...
         end select
      end block
   end subroutine a

   !  compiles successfully if name is not 'select'
   subroutine select
   end subroutine select

end module m


Error messages are:

select_within_block.f90:23:20:

   23 |    subroutine select
      |                    1
Error: VARIABLE attribute of ‘select’ conflicts with PROCEDURE attribute at (1)
select_within_block.f90:24:6:

   24 |    end subroutine select
      |      1
Error: Expecting END MODULE statement at (1)
select_within_block.f90:5:22:

    5 |    public :: a, select
      |                      1
Error: Symbol ‘select’ at (1) has no IMPLICIT type

The second and third errors are clearly consequences of the first error, which
makes no sense to me.

There are easy workarounds: rename subroutine select; replace the block
construct with a do construct containing a final unconditional exit.

While this failed compilation involved a very specific choice of procedure
name, I suspect it is merely one case of a wider problem.

While I first encountered this with version 4.9.2, I waited until I could check
(after an upgrade) with a recent version of the compiler before I spent the
time to cut down a large module to a minimal example that exhibited the
problem.

There was no preprocessed file (*.i*) produced from the failed compilation.

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-02-20
     Ever confirmed|0                           |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The error also disappears if the order of the subroutines is interchanged.

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[johnww at tds dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850

--- Comment #2 from John Wingate <johnww at tds dot net> ---
I forgot to mention in the original description that the error does not occur
if the SELECT CASE is removed.

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to John Wingate from comment #2)
> I forgot to mention in the original description that the error does not
> occur if the SELECT CASE is removed.

Right.  The testcase case be slightly reduced to the almost bare minimum:

module m
  implicit none
  private
  public :: select
contains
  subroutine a
    block
      select case (1)
      end select
    end block
  end subroutine a
  !  compiles successfully if name is not 'select'
  subroutine select
  end subroutine select
end module m

Either interchanging the subroutines, commenting "public :: select",
commenting the "select case" block, or commenting "block" while keeping
its contents avoids the error.

Adding -fdump-fortran-original shows why gfortran hits some artifical
conflict:

Namespace: A-Z: (UNKNOWN 0)
procedure name = m
  symtree: 'a'           || symbol: 'a'            
    type spec : (UNKNOWN 0)
    attributes: (PROCEDURE MODULE-PROC  SUBROUTINE IMPLICIT-PURE CONTAINED)
  symtree: 'm'           || symbol: 'm'            
    type spec : (UNKNOWN 0)
    attributes: (MODULE )
  symtree: 'select'      || symbol: 'select'       
    type spec : (UNKNOWN 0)
    attributes: (VARIABLE PUBLIC )

[...]

I have no idea how the above code tricks gfortran into thinking there is
a variable 'select' ...