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.

Reply via email to