public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
@ 2010-10-20 18:05 ` burnus at gcc dot gnu.org
[not found] ` <20101020180547.5917F1C001E0@msfrf2213.sfr.fr>
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-10-20 18:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] ` <20101020180547.5917F1C001E0@msfrf2213.sfr.fr>
@ 2010-10-20 18:22 ` Mikael Morin
0 siblings, 0 replies; 14+ messages in thread
From: Mikael Morin @ 2010-10-20 18:22 UTC (permalink / raw)
To: gcc-bugs
> two() = 7
I don't see how it is possible to distinguish between a statement function and
an assignment here.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
2010-10-20 18:05 ` [Bug fortran/40054] [F08] Pointer functions as lvalue burnus at gcc dot gnu.org
[not found] ` <20101020180547.5917F1C001E0@msfrf2213.sfr.fr>
@ 2010-11-15 16:22 ` burnus at gcc dot gnu.org
2011-06-28 15:50 ` janus at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-11-15 16:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-11-15 16:22 ` burnus at gcc dot gnu.org
@ 2011-06-28 15:50 ` janus at gcc dot gnu.org
2011-07-03 11:28 ` janus at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: janus at gcc dot gnu.org @ 2011-06-28 15:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-06-28 15:50 ` janus at gcc dot gnu.org
@ 2011-07-03 11:28 ` janus at gcc dot gnu.org
2011-07-03 11:33 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: janus at gcc dot gnu.org @ 2011-07-03 11:28 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-07-03 11:28 ` janus at gcc dot gnu.org
@ 2011-07-03 11:33 ` janus at gcc dot gnu.org
2011-07-03 15:44 ` janus at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: janus at gcc dot gnu.org @ 2011-07-03 11:33 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2011-07-03 11:33 ` janus at gcc dot gnu.org
@ 2011-07-03 15:44 ` janus at gcc dot gnu.org
2011-07-03 16:20 ` kargl at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: janus at gcc dot gnu.org @ 2011-07-03 15:44 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2011-07-03 15:44 ` janus at gcc dot gnu.org
@ 2011-07-03 16:20 ` kargl at gcc dot gnu.org
2011-07-03 16:25 ` janus at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-07-03 16:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2011-07-03 16:20 ` kargl at gcc dot gnu.org
@ 2011-07-03 16:25 ` janus at gcc dot gnu.org
2011-07-03 16:29 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: janus at gcc dot gnu.org @ 2011-07-03 16:25 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2011-07-03 16:25 ` janus at gcc dot gnu.org
@ 2011-07-03 16:29 ` burnus at gcc dot gnu.org
2011-07-03 17:13 ` sgk at troutmask dot apl.washington.edu
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-07-03 16:29 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2011-07-03 16:29 ` burnus at gcc dot gnu.org
@ 2011-07-03 17:13 ` sgk at troutmask dot apl.washington.edu
2013-10-25 7:09 ` quantheory at gmail dot com
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2011-07-03 17:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2011-07-03 17:13 ` sgk at troutmask dot apl.washington.edu
@ 2013-10-25 7:09 ` quantheory at gmail dot com
2015-09-28 21:19 ` pault at gcc dot gnu.org
2015-09-28 21:27 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: quantheory at gmail dot com @ 2013-10-25 7:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2013-10-25 7:09 ` quantheory at gmail dot com
@ 2015-09-28 21:19 ` pault at gcc dot gnu.org
2015-09-28 21:27 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-09-28 21:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/40054] [F08] Pointer functions as lvalue
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2015-09-28 21:19 ` pault at gcc dot gnu.org
@ 2015-09-28 21:27 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-09-28 21:27 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-09-28 21:27 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-40054-4@http.gcc.gnu.org/bugzilla/>
2010-10-20 18:05 ` [Bug fortran/40054] [F08] Pointer functions as lvalue burnus at gcc dot gnu.org
[not found] ` <20101020180547.5917F1C001E0@msfrf2213.sfr.fr>
2010-10-20 18:22 ` Mikael Morin
2010-11-15 16:22 ` burnus at gcc dot gnu.org
2011-06-28 15:50 ` janus at gcc dot gnu.org
2011-07-03 11:28 ` janus at gcc dot gnu.org
2011-07-03 11:33 ` janus at gcc dot gnu.org
2011-07-03 15:44 ` janus at gcc dot gnu.org
2011-07-03 16:20 ` kargl at gcc dot gnu.org
2011-07-03 16:25 ` janus at gcc dot gnu.org
2011-07-03 16:29 ` burnus at gcc dot gnu.org
2011-07-03 17:13 ` sgk at troutmask dot apl.washington.edu
2013-10-25 7:09 ` quantheory at gmail dot com
2015-09-28 21:19 ` pault at gcc dot gnu.org
2015-09-28 21:27 ` pault at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).