[Bug fortran/63552] New: [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[Bug fortran/63552] New: [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[burnus at gcc dot gnu.org]

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

            Bug ID: 63552
           Summary: [OOP] Type-bound procedures rejected as actual
                    argument to dummy procedure
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

The following code compiles with, e.g., Cray's ftn but fails with gfortran 5
with:

call co_reduce(a,x%tbp)
                      1
Error: Expected argument list at (1)


module m
  type t
    procedure(f), pointer, nopass :: ppc
  contains
    procedure, nopass :: tbp => f
  end type t
contains
  pure function f(a,b)
    real :: a,b
    value :: a
    intent(in) :: b
    f = 0
  end function f
end module m

use m
!intrinsic co_reduce
integer :: a
type(t) :: x
!call co_reduce(a,x%ppc)
call co_reduce(a,x%tbp)
end

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-16
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed from 4.6 up to trunk (5.0). 4.5 gives

pr63552.f90:8.19:

  pure function f(a,b)
                   1
Error: Argument 'a' of pure function 'f' at (1) must be INTENT(IN)
pr63552.f90:16.5:

use m
     1
Fatal Error: Can't open module file 'm.mod' for reading at (1): No such file or
directory

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> call co_reduce(a,x%tbp)
>                       1
> Error: Expected argument list at (1)

That error comes from 'gfc_match_varspec' (in primary.c). In general I think
it's not possible to decide at parse-time whether the TBP should have an
argument list here or not (depending on whether the dummy is a procedure, which
may not be known while parsing).

The error should probably move to resolution stage, where all argument checking
is done.

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
This draft patch gets rid of the error and regtests cleanly:


Index: gcc/fortran/primary.c
===================================================================
--- gcc/fortran/primary.c    (Revision 219098)
+++ gcc/fortran/primary.c    (Arbeitskopie)
@@ -1987,11 +1987,13 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
         {
           if (sub_flag)
         primary->value.compcall.actual = NULL;
-          else
+          else if (!matching_actual_arglist)
         {
           gfc_error ("Expected argument list at %C");
           return MATCH_ERROR;
         }
+          else
+        primary->expr_type = EXPR_VARIABLE;
         }

       break;


However I then get another error on the test case in comment 0:

 call co_reduce(a,x%tbp)
                 1
Error: OPERATOR argument at (1) must be a PURE function


This is obviously bogus since 'tbp' is bound to a PURE function. For the
commented-out line I get:

call co_reduce(a,x%ppc)
               1 2
Fehler: A argument at (1) has type INTEGER(4) but the function passed as
OPERATOR at (2) returns REAL(4)


(which I guess is diagnosed correctly?)

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> For the commented-out line I get:
> 
> call co_reduce(a,x%ppc)
>                1 2
> Fehler: A argument at (1) has type INTEGER(4) but the function passed as
> OPERATOR at (2) returns REAL(4)
> 
> (which I guess is diagnosed correctly?)

Thus the test case is invalid. Here is a corrected version:

module m
  type t
    procedure(f), pointer, nopass :: ppc
  contains
    procedure, nopass :: tbp => f
  end type
contains
  pure integer function f(a,b)
    integer, intent(in) :: a,b
    f = 0
  end function
end module

use m
integer :: a
type(t) :: x
! call co_reduce(a,f)
! call co_reduce(a,x%ppc)
call co_reduce(a,x%tbp)
end

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> This draft patch gets rid of the error and regtests cleanly:

Unfortunately this patch is far from complete. What needs to be done is to use
the PPC component of the vtab in the actual-argument expression.

There are two cases to be handled: Polymorphic and non-polymorphic variables.

Here is a test case without CO_REDUCE, which covers both cases:


module m
  type t
  contains
    procedure, nopass :: tbp => f
  end type
contains
  pure integer function f(a,b)
    integer, intent(in) :: a,b
    f = a+b
  end function
end module

use m
integer :: a
class(t), allocatable :: x
type(t) :: y

call sub(x%tbp)
call sub(y%tbp)

contains
  subroutine sub(arg)
    procedure(f) :: arg
    print *,f(1,2)
  end subroutine
end


I'm working on a patch.

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Ian Harvey from comment #6)
> Note that using a type bound procedure (versus a procedure component) as an
> actual argument is an extension to Fortran 2008.

Can you pinpoint this in the standard? At a glance, it seems to be supported:

R1223 procedure-designator  is  procedure-name
                            or  proc-component-ref
                            or  data-ref % binding-name

"12.2.2.3 Dummy procedures
A dummy argument that is specified to be a procedure or appears as the
procedure designator in a procedure reference is a dummy procedure. A dummy
procedure with the POINTER attribute is a dummy procedure pointer."

Quotes from the Fortran 2015 draft J3/14-007r2.

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[ian_harvey at bigpond dot com]

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

--- Comment #8 from Ian Harvey <ian_harvey at bigpond dot com> ---
For clarity - there is a difference between a procedure as an actual argument
and a procedure reference (something with parentheses and maybe arguments
following) that is part of an expression that is an actual argument.  See also
definition of "procedure reference" in 1.3.123.4 - noting reference "requires
execution at that point".  A procedure as an actual argument does not require
execution of the procedure at the time of argument association (a procedure
reference may occur later through the corresponding dummy procedure).

The syntax rule for an /actual-arg/ in 14-007r2 is R1225.  None of the child
syntax rules of R1225 permit a type bound procedure, noting that a binding of a
type is not a component of a type.

R1223 in 14-007r2 is only used in the forms of procedure reference
(/function-reference/ or /call-stmt/).  It is not relevant to procedures as
actual arguments.

[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to Ian Harvey from comment #8)
> The syntax rule for an /actual-arg/ in 14-007r2 is R1225.  None of the child
> syntax rules of R1225 permit a type bound procedure, noting that a binding
> of a type is not a component of a type.

Thanks for pointing that out, Ian. I think none of us was aware of that. I'd
even say "too bad", since I posted a somewhat working patch for this feature
yesterday ;)

https://gcc.gnu.org/ml/fortran/2015-01/msg00012.html

Do you have any insight (or suspicion) on why it was not allowed in the
standard? Do you think it would be a good idea to implement it in gfortran
anyway (as an extension, i.e. rejected with -std=f2008). Would it be feasible
to allow it in the upcoming F2015?