[Bug fortran/40054] [F08] Pointer functions as lvalue

[Bug fortran/40054] [F08] Pointer functions as lvalue

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-20 18:05:23 UTC ---
Another example (from PR 46100):

two() = 7
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end



Fails with:

  function two ()
              1
two() = 7
   2
Error: Procedure 'two' at (1) is already defined at (2)

  function two ()
  1
Error: INTERNAL-PROC procedure at (1) is already declared as STATEMENT-PROC
procedure

Re: [Bug fortran/40054] [F08] Pointer functions as lvalue

[Mikael Morin]

> two() = 7
I don't see how it is possible to distinguish between a statement function and 
an assignment here.

[Bug fortran/40054] [F08] Pointer functions as lvalue

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-15 16:17:54 UTC ---
Remember also to update check.c's variable_check.

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #4 from janus at gcc dot gnu.org 2011-06-28 15:49:54 UTC ---
cf. also PR 49562

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #5 from janus at gcc dot gnu.org 2011-07-03 11:27:55 UTC ---
(In reply to comment #4)
> cf. also PR 49562

after PR49562 is fixed on trunk, type-bound pointer functions already work (in
contrast to ordinary, non-type-bound pointer functions)

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #6 from janus at gcc dot gnu.org 2011-07-03 11:32:42 UTC ---
(In reply to comment #2)
> 
> two() = 7
> contains
>   function two ()
>     integer, pointer  :: two
>     allocate(two)
>   end function two
> end
> 
> Fails with:
> 
>   function two ()
>               1
> two() = 7
>    2
> Error: Procedure 'two' at (1) is already defined at (2)

Huh. Since "two() = 7" is in fact a valid statement function declaration,
gfortran might even be right to reject this, right?

However, the following (valid?) variant is currently rejected:

print *,"hello"
two() = 7
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end


two() = 7
         1
Error: Unexpected STATEMENT FUNCTION statement at (1)

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #7 from janus at gcc dot gnu.org 2011-07-03 15:43:39 UTC ---
I think it will be very hard (if not impossible) to implement this, while
maintaining support for statement functions at the same time. In particular,
how is one supposed to interpret a statement like:

f (x) = x + 1

Is this a statement function declaration? Or rather an assignment to the result
of a pointer-valued function f, which is defined further down the road? In many
situations this seems to be indistinguishable (or one can only decide it at
resolution stage, where the function f has been parsed already, if it is
there). Or am I missing some restriction in the standard?

In any case, statement functions are obsolescent since F95, so would it be an
option to not support them with -std=f2008?

[Bug fortran/40054] [F08] Pointer functions as lvalue

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

kargl at gcc dot gnu.org changed:

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

--- Comment #8 from kargl at gcc dot gnu.org 2011-07-03 16:19:24 UTC ---
(In reply to comment #7)
> I think it will be very hard (if not impossible) to implement this, while
> maintaining support for statement functions at the same time. In particular,
> how is one supposed to interpret a statement like:
> 
> f (x) = x + 1
> 
> Is this a statement function declaration? Or rather an assignment to the result
> of a pointer-valued function f, which is defined further down the road? In many
> situations this seems to be indistinguishable (or one can only decide it at
> resolution stage, where the function f has been parsed already, if it is
> there). Or am I missing some restriction in the standard?
> 
> In any case, statement functions are obsolescent since F95, so would it be an
> option to not support them with -std=f2008?

Obsolescent does not mean deleted.  Unfortunately, statement functions
are still valid Fortran.

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #9 from janus at gcc dot gnu.org 2011-07-03 16:24:53 UTC ---
(In reply to comment #8)
> > In any case, statement functions are obsolescent since F95, so would it be an
> > option to not support them with -std=f2008?
> 
> Obsolescent does not mean deleted.  Unfortunately, statement functions
> are still valid Fortran.

Yes, I am aware of that. Do you have an idea how to implement both features at
the same time, Steve?

[Bug fortran/40054] [F08] Pointer functions as lvalue

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-03 16:29:01 UTC ---
(In reply to comment #7)
> I think it will be very hard (if not impossible) to implement this, while
> maintaining support for statement functions at the same time. In particular,
> how is one supposed to interpret a statement like:
> f (x) = x + 1

That depends on the context. The function "f(x)" is only a variable if "f"
returns a pointer - and those functions are required to have an explicit
interface (cf. "12.4.2.2 Explicit interface").

Thus, the ambiguity can only occur if one host-associates an explicit interface
of "f". But the following makes clear how to interpret the program in that case
(from "12.6.4 Statement function"):

"The definition of a statement function with the same name as an accessible
entity from the host shall be preceded by the declaration of its type in a type
declaration statement."


> In any case, statement functions are obsolescent since F95, so would it be an
> option to not support them with -std=f2008?

No. They are just obsolescent - not deleted:

"Better methods existed in Fortran 90 and Fortran 95 for each obsolescent
feature. It is recommended that programmers use these better methods in new
programs and convert existing code to these methods. [...]  A future revision
of this part of ISO/IEC 1539 might delete an obsolescent feature if its use has
become insignificant." (From "1.7.3 Nature of obsolescent features")

Besides, with -std=gnu, we want to support both old and Fortran 2008 conform
programs ...

[Bug fortran/40054] [F08] Pointer functions as lvalue

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-07-03 17:12:15 UTC ---
On Sun, Jul 03, 2011 at 04:25:39PM +0000, janus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054
> 
> --- Comment #9 from janus at gcc dot gnu.org 2011-07-03 16:24:53 UTC ---
> (In reply to comment #8)
> > > In any case, statement functions are obsolescent since F95, so would it be an
> > > option to not support them with -std=f2008?
> > 
> > Obsolescent does not mean deleted.  Unfortunately, statement functions
> > are still valid Fortran.
> 
> Yes, I am aware of that. Do you have an idea how to implement both features at
> the same time, Steve?
> 

With your first example,

two() = 7
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end

I think two() should be treated as a pointer function because
the standard states:

   The definition of a statement function with the same name
   as an accessible entity from the host shall be preceded by the
   declaration of its type in a type declaration statement.

For two() to be a statement function one would need to have
for example,

real two
two() = 7
contains
  !
  ! Is this now an error due to a redefinition of two() ???
  !
  function two ()  
    integer, pointer  :: two
    allocate(two)
  end function two
end

Also, as Tobias' noted an explicit interface is needed for a
pointer function.

[Bug fortran/40054] [F08] Pointer functions as lvalue

[quantheory at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

Sean Santos <quantheory at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |quantheory at gmail dot com

--- Comment #12 from Sean Santos <quantheory at gmail dot com> ---
I think Tobias already has this figured, but my view of this was as follows.

These define statement functions yielding 7:

--- Example 1 ---

two() = 7
end

--- Example 2 ---

module foo
contains
  function two()
    integer, pointer  :: two
    allocate(two)
  end function two

  subroutine bar()
    ! Fortran 2008 (12.6.4) says that this is necessary to hide
    ! the host-associated declaration
    integer :: two
    two() = 7
  end subroutine bar
end module foo

These refer to the pointer function:

--- Example 1 ---

two() = 7
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end

--- Example 2 ---

module foo
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end module

program
use foo
two() = 7
end program

--- Example 3 ---

module foo
contains
  function two()
    integer, pointer  :: two
    allocate(two)
  end function two

  subroutine bar()
    two() = 7
  end subroutine bar
end module foo

And these are not allowed at all based on 11.2.2.8 and 16.3.1.3, because they
result in a name clash:

--- Example 1 ---

integer :: two
two() = 7
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end

--- Example 2 ---

module foo
contains
  function two ()
    integer, pointer  :: two
    allocate(two)
  end function two
end module

program
use foo
integer :: two
two() = 7
end program

[Bug fortran/40054] [F08] Pointer functions as lvalue

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Mon Sep 28 21:18:38 2015
New Revision: 228222

URL: https://gcc.gnu.org/viewcvs?rev=228222&root=gcc&view=rev
Log:
2015-09-28  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40054
        PR fortran/63921
        * decl.c (get_proc_name): Return if statement function is
        found.
        * expr.c (gfc_check_vardef_context): Add error return for
        derived type expression lacking the derived type itself.
        * match.c (gfc_match_ptr_fcn_assign): New function.
        * match.h : Add prototype for gfc_match_ptr_fcn_assign.
        * parse.c : Add static flag 'in_specification_block'.
        (decode_statement): If in specification block match a statement
        function, then, if no error arising from statement function
        matching, try to match pointer function assignment.
        (parse_interface): Set 'in_specification_block' on exiting from
        parse_spec.
        (parse_spec): Set and then reset 'in_specification_block'.
        (gfc_parse_file): Set 'in_specification_block'.
        * resolve.c (get_temp_from_expr): Extend to include functions
        and array constructors as rvalues..
        (resolve_ptr_fcn_assign): New function.
        (gfc_resolve_code): Call it on finding a pointer function as an
        lvalue. If valid or on error, go back to start of resolve_code.
        * symbol.c (gfc_add_procedure): Add a sentence to the error to
        flag up the ambiguity between a statement function and pointer
        function assignment at the end of the specification block.

2015-09-28  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40054
        PR fortran/63921
        * gfortran.dg/fmt_tab_1.f90: Change from run to compile and set
        standard as legacy.
        * gfortran.dg/fmt_tab_2.f90: Add extra tab error.
        * gfortran.dg/function_types_3.f90: Change error message to
        "Type inaccessible...."
        * gfortran.dg/ptr_func_assign_1.f08: New test.
        * gfortran.dg/ptr_func_assign_2.f08: New test.

2015-09-25  Mikael Morin  <mikael.morin@sfr.fr>

        PR fortran/40054
        PR fortran/63921
        * gfortran.dg/ptr_func_assign_3.f08: New test.
        * gfortran.dg/ptr_func_assign_4.f08: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/ptr_func_assign_1.f08
    trunk/gcc/testsuite/gfortran.dg/ptr_func_assign_2.f08
    trunk/gcc/testsuite/gfortran.dg/ptr_func_assign_3.f08
    trunk/gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/match.h
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/fmt_tab_1.f90
    trunk/gcc/testsuite/gfortran.dg/fmt_tab_2.f90
    trunk/gcc/testsuite/gfortran.dg/function_types_3.f90

[Bug fortran/40054] [F08] Pointer functions as lvalue

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pault at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #14 from Paul Thomas <pault at gcc dot gnu.org> ---
Barring the remaining ambiguity at the end of the specification block, fixed on
trunk.

Thanks for the PR.

Paul