[Bug fortran/109275] New: Bad error messages for interfaces describing surrounding program unit

["rhidalgochar at bloomberg dot net" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 109275
           Summary: Bad error messages for interfaces describing
                    surrounding program unit
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rhidalgochar at bloomberg dot net
  Target Milestone: ---

The following example, where an interface is defined for the surrounding
program unit fails to compile:

      function foo(arg1) result(res)

      interface foo
        function foo(arg1)
          integer*2 foo(3)
          integer*8 arg1
        end function foo
      end interface

      integer*2 res(3)
      integer*8 arg1
      res = (/1,2,int(arg1,4)/)
      end function

Giving the error:

recursive-interface.f:4:8:

    4 |         function foo(arg1)
      |        1
Error: Procedure pointer result ‘foo’ at (1) is missing the pointer attribute

Given you can use this function with that interface, this appears to be an
incorrect warning.

It gives even stranger warnings if you follow its advice and add the pointer
attribute to foo in the interface (i.e. integer*2, pointer :: foo(3)):

recursive-interface.f:4:8:

    4 |         function foo(arg1)
      |        1
Error: Array pointer ‘ppr@’ at (1) must have a deferred shape or assumed rank
recursive-interface.f:1:6:

    1 |       function foo(arg1) result(res)
      |      1
Error: Array pointer ‘foo’ at (1) must have a deferred shape or assumed rank

It appears that "ppr@" is some internal return variable that should not be
getting exposed. Following this advice further and making foo assumed shape
(foo(:)) it goes back to complaining about it not having the pointer attribute
even though it does.

While I don't see any reason why a correctly defined interface would not be
allowed, especially if it's not even used and result is used to disambiguate
the symbol, other compilers do fail to compile and complain about using an
interface with the same name as the surrounding program unit. XLF complained
for normal interfaces, while Sun Studio just complains for generic interface.

GFortrans error message should at least be more informative, explicitly saying
it's not allowed if this is the case.

I came across this issue because a library had an include with many interfaces,
and was then trying to use some of those interfaces in the definitions of those
program units.