Resolving names in function returns types

Hello!
I stumbled upon yet another flang bug (or feature?)
So, there’s a proprietary codebase that has a code like this: a.f90 · GitHub
gfortran with all warnings enabled compiles it one fair warning:

$ gfortran -Wall -Wextra -pedantic  b.f90 c.f90 a.f90
a.f90:3:29:

    3 |     real(q) function foo(y, z)
      |                             1
Warning: Unused dummy argument ‘z’ at (1) [-Wunused-dummy-argument]

nvfortran has no problems with the code either.
Yet, flang refuses to compile it (in both LLVM upstream and fir-dev branch):

$ build/bin/flang-new b.f90 c.f90 a.f90
error: Semantic errors in a.f90
./a.f90:3:10: error: Must be a constant value
      real(q) function foo(y, z)
           ^
./a.f90:4:13: error: Cannot use-associate 'q'; it is already declared in this scope
          use c
              ^
./a.f90:3:10: Previous declaration of 'q'
      real(q) function foo(y, z)
           ^
./a.f90:5:14: error: Must have INTEGER type, but is REAL(4)
          real(q) :: y
               ^

To be honest, I’m not sure if the code is complaint with the Fortran specification. But even if it is not, I think it should be implemented as an extension with a dedicated flag, because major compilers support it by default and I think there’s a lot of code that is written as aforementioned.

What do you think about it? I’d like to implement the extension and contribute it back.

If q is defined in the body of foo, this is a known problem. A fix is pending in phabricator (⚙ D123705 [flang] Defer all function result type processing) and will be integrated soon.

1 Like

q is imported in the body of foo, probably this “defined” also