Bug 94348 - gfortran 8/9 reject module procedure definition in same module as function interface (edit)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug 94348 - gfortran 8/9 reject module procedure definition in same module as function interface (edit)

Damian Rouson-4
See the transcript below.

Damian


$ cat foo.f90

module foo_module
  implicit none

  interface
     module function foo() result(bar)
       implicit none
       integer bar
     end function
  end interface

contains
  module procedure foo
    bar = 0
  end procedure
end module

$ gfortran -c foo.f90

foo.f90:13:7:


   13 |     bar = 0

      |       1

Error: Symbol 'bar' at (1) has no IMPLICIT type

$ gfortran --version

GNU Fortran (Homebrew GCC 9.2.0_3) 9.2.0
Reply | Threaded
Open this post in threaded view
|

[Patch][Fortran] Fix result-variable handling of MODULE PROCEDURE (PR94348) (was: Bug 94348 - gfortran 8/9 reject module procedure definition in same module as function interface (edit))

Tobias Burnus-3
In the the PR, the question was raised whether the code
is valid or not. I believe it is, based on the general
wording but also on the following quote from F2019:

"If it is a function its result name is determined
by the FUNCTION statement in the interface body."

(Last sentence before the final "Note" in
"15.6.2.5 Separate module procedures".)

As testing shows – and matching the description in
the PR – the result-variable name is already handled
when used in submodules; hence, the use-assoc check.

OK for the trunk?

Tobias

PS: The issue has been reported against GCC 8/9;
any sentiment regarding backporting the fix
to 9 (or even both?) – or is trunk enough,
given that GCC 10 will be release relatively soonish?

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter

modproc.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch][Fortran] Fix result-variable handling of MODULE PROCEDURE (PR94348) (was: Bug 94348 - gfortran 8/9 reject module procedure definition in same module as function interface (edit))

gcc - fortran mailing list
Hi Tobias,

This is yet another one that I was intending to take a look at. Many
thanks for the fix.

This is certainly OK for trunk and I would suggest that it be applied
to 9-branch as well.

Cheers

Paul

On Fri, 27 Mar 2020 at 16:28, Tobias Burnus <[hidden email]> wrote:

>
> In the the PR, the question was raised whether the code
> is valid or not. I believe it is, based on the general
> wording but also on the following quote from F2019:
>
> "If it is a function its result name is determined
> by the FUNCTION statement in the interface body."
>
> (Last sentence before the final "Note" in
> "15.6.2.5 Separate module procedures".)
>
> As testing shows – and matching the description in
> the PR – the result-variable name is already handled
> when used in submodules; hence, the use-assoc check.
>
> OK for the trunk?
>
> Tobias
>
> PS: The issue has been reported against GCC 8/9;
> any sentiment regarding backporting the fix
> to 9 (or even both?) – or is trunk enough,
> given that GCC 10 will be release relatively soonish?
>
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter



--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein