public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
@ 2010-12-08 13:07 burnus at gcc dot gnu.org
2010-12-08 13:08 ` [Bug fortran/46849] " burnus at gcc dot gnu.org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-08 13:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
Summary: [OOP] MODULE PROCEDURE resolution does not work in
BLOCK or SELECT TYPE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: burnus@gcc.gnu.org
CC: janus@gcc.gnu.org, domob@gcc.gnu.org
The following problem has been reported by Reinhold Bader.
select type (p => fun%options)
type is (qdr_opt_qag)
p%f = fgsl_function_init(fun_qag)
end select
Is rejected with a current GCC 4.6 with:
pmr.f90:35.39:
p%f = fgsl_function_init(fun_qag)
1
Error: Symbol 'fun_qag' at (1) has no IMPLICIT type
f951: internal compiler error: in gfc_enforce_clean_symbol_state, at
fortran/symbol.c:3472
Here, "fun_qag" is a module procedure. It works if one flips the order of
"fun_qag" and the calling procedure. It also works if one uses the line:
fun%options%f = fgsl_function_init(fun_qag)
as long as the line is neither in a BLOCK nor in a SELECT TYPE. Seemingly,
resolve_symbol does not search in the module name space!
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
@ 2010-12-08 13:08 ` burnus at gcc dot gnu.org
2010-12-08 13:30 ` burnus at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-08 13:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-08 13:08:43 UTC ---
Created attachment 22685
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22685
Test case
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
2010-12-08 13:08 ` [Bug fortran/46849] " burnus at gcc dot gnu.org
@ 2010-12-08 13:30 ` burnus at gcc dot gnu.org
2010-12-08 13:48 ` janus at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-08 13:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.5.1, 4.6.0
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-08 13:30:35 UTC ---
For the reject-valid part: See comment 0.
Reduced test case for the error-recovery ICE:
module m
implicit none
type :: dt
end type
contains
subroutine test(fun)
class(dt) :: fun
call extern(not_existing) ! Error: No implicit type
select type (fun)
type is (dt) ! TYPE IS is required for the ICE
end select
end subroutine test
end module m
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
2010-12-08 13:08 ` [Bug fortran/46849] " burnus at gcc dot gnu.org
2010-12-08 13:30 ` burnus at gcc dot gnu.org
@ 2010-12-08 13:48 ` janus at gcc dot gnu.org
2010-12-13 21:59 ` janus at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-08 13:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.12.08 13:48:45
Ever Confirmed|0 |1
--- Comment #3 from janus at gcc dot gnu.org 2010-12-08 13:48:45 UTC ---
Here is a reduced test case for the rejects-valid part, without CLASS and
ISO_C_BINDING:
implicit none
block
call init(fun)
end block
contains
subroutine init(func)
real, external :: func
end subroutine
real function fun()
fun = 1.1
end function
end
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2010-12-08 13:48 ` janus at gcc dot gnu.org
@ 2010-12-13 21:59 ` janus at gcc dot gnu.org
2010-12-14 8:36 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-13 21:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #4 from janus at gcc dot gnu.org 2010-12-13 21:59:21 UTC ---
(In reply to comment #3)
> Here is a reduced test case for the rejects-valid part, without CLASS and
> ISO_C_BINDING:
Not sure if it's the perfectly right thing to do, but the following patch fixes
the test cases in comment #3 and #1:
Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c (revision 167765)
+++ gcc/fortran/symbol.c (working copy)
@@ -2717,7 +2717,7 @@ gfc_get_sym_tree (const char *name, gfc_namespace
/* This doesn't usually happen during resolution. */
if (ns == NULL)
- ns = gfc_current_ns;
+ ns = gfc_find_proc_namespace (gfc_current_ns);
/* Try to find the symbol in ns. */
st = gfc_find_symtree (ns->sym_root, name);
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2010-12-13 21:59 ` janus at gcc dot gnu.org
@ 2010-12-14 8:36 ` burnus at gcc dot gnu.org
2010-12-14 12:13 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-14 8:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-14 08:36:07 UTC ---
(In reply to comment #4)
> @@ -2717,7 +2717,7 @@ gfc_get_sym_tree (const char *name, gfc_namespace
> if (ns == NULL)
> - ns = gfc_current_ns;
> + ns = gfc_find_proc_namespace (gfc_current_ns);
That looks wrong. gfc_get_sym_tree is called several times in decl.c, match.c,
parse.c and primary.c with NULL - I fear that this patch will cause symbols end
up in the wrong name space.
I think one should rather do something like the following - though one might
need to be a bit more careful and restrict it, e.g., to procedures.
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11784,7 +11784,7 @@ resolve_symbol (gfc_symbol *sym)
for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
{
symtree = gfc_find_symtree (ns->sym_root, sym->name);
- if (symtree && symtree->n.sym->generic)
+ if (symtree) /* && symtree->n.sym->generic)*/
{
this_symtree = gfc_find_symtree (gfc_current_ns->sym_root,
sym->name);
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2010-12-14 8:36 ` burnus at gcc dot gnu.org
@ 2010-12-14 12:13 ` janus at gcc dot gnu.org
2010-12-14 18:31 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-14 12:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #6 from janus at gcc dot gnu.org 2010-12-14 12:13:04 UTC ---
(In reply to comment #5)
> > @@ -2717,7 +2717,7 @@ gfc_get_sym_tree (const char *name, gfc_namespace
> > if (ns == NULL)
> > - ns = gfc_current_ns;
> > + ns = gfc_find_proc_namespace (gfc_current_ns);
>
> That looks wrong. gfc_get_sym_tree is called several times in decl.c, match.c,
> parse.c and primary.c with NULL - I fear that this patch will cause symbols end
> up in the wrong name space.
Yes, you're right. It produces a fair number of regressions ...
> I think one should rather do something like the following - though one might
> need to be a bit more careful and restrict it, e.g., to procedures.
>
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -11784,7 +11784,7 @@ resolve_symbol (gfc_symbol *sym)
> for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
> {
> symtree = gfc_find_symtree (ns->sym_root, sym->name);
> - if (symtree && symtree->n.sym->generic)
> + if (symtree) /* && symtree->n.sym->generic)*/
> {
> this_symtree = gfc_find_symtree (gfc_current_ns->sym_root,
> sym->name);
I agree that this is better, though it still causes some regressions. I will
now test the following variant:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 167790)
+++ gcc/fortran/resolve.c (working copy)
@@ -11784,7 +11784,7 @@ resolve_symbol (gfc_symbol *sym)
for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
{
symtree = gfc_find_symtree (ns->sym_root, sym->name);
- if (symtree && symtree->n.sym->generic)
+ if (symtree && symtree->n.sym->attr.flavor == FL_PROCEDURE)
{
this_symtree = gfc_find_symtree (gfc_current_ns->sym_root,
sym->name);
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2010-12-14 12:13 ` janus at gcc dot gnu.org
@ 2010-12-14 18:31 ` janus at gcc dot gnu.org
2010-12-17 12:32 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-14 18:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #7 from janus at gcc dot gnu.org 2010-12-14 18:30:48 UTC ---
(In reply to comment #6)
> I agree that this is better, though it still causes some regressions. I will
> now test the following variant:
>
> Index: gcc/fortran/resolve.c
> ===================================================================
> --- gcc/fortran/resolve.c (revision 167790)
> +++ gcc/fortran/resolve.c (working copy)
> @@ -11784,7 +11784,7 @@ resolve_symbol (gfc_symbol *sym)
> for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
> {
> symtree = gfc_find_symtree (ns->sym_root, sym->name);
> - if (symtree && symtree->n.sym->generic)
> + if (symtree && symtree->n.sym->attr.flavor == FL_PROCEDURE)
> {
> this_symtree = gfc_find_symtree (gfc_current_ns->sym_root,
> sym->name);
Unfortunately this also triggers a few regressions, but the following regtests
cleanly:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 167790)
+++ gcc/fortran/resolve.c (working copy)
@@ -11784,7 +11784,9 @@ resolve_symbol (gfc_symbol *sym)
for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
{
symtree = gfc_find_symtree (ns->sym_root, sym->name);
- if (symtree && symtree->n.sym->generic)
+ if (symtree && (symtree->n.sym->generic ||
+ (symtree->n.sym->attr.flavor == FL_PROCEDURE
+ && sym->ns->construct_entities)))
{
this_symtree = gfc_find_symtree (gfc_current_ns->sym_root,
sym->name);
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2010-12-14 18:31 ` janus at gcc dot gnu.org
@ 2010-12-17 12:32 ` janus at gcc dot gnu.org
2010-12-17 12:34 ` janus at gcc dot gnu.org
2011-02-14 10:30 ` janus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-17 12:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #8 from janus at gcc dot gnu.org 2010-12-17 12:31:57 UTC ---
Author: janus
Date: Fri Dec 17 12:31:54 2010
New Revision: 167978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167978
Log:
2010-12-17 Janus Weil <janus@gcc.gnu.org>
Tobias Burnus <burnus@gcc.gnu.org>
PR fortran/46849
* resolve.c (resolve_symbol): Remove symbols that wrongly ended up
in a local BLOCK namespace.
2010-12-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/46849
* gfortran.dg/block_9.f08: New.
Added:
trunk/gcc/testsuite/gfortran.dg/block_9.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2010-12-17 12:32 ` janus at gcc dot gnu.org
@ 2010-12-17 12:34 ` janus at gcc dot gnu.org
2011-02-14 10:30 ` janus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-17 12:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #9 from janus at gcc dot gnu.org 2010-12-17 12:34:11 UTC ---
r167978 fixes the rejects-valid part, i.e. comment #3.
ToDo: ICE-on-invalid in comment #2.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2010-12-17 12:34 ` janus at gcc dot gnu.org
@ 2011-02-14 10:30 ` janus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-14 10:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #10 from janus at gcc dot gnu.org 2011-02-14 10:29:20 UTC ---
(In reply to comment #9)
> ToDo: ICE-on-invalid in comment #2.
This is now being tracked in PR 47730. Closing this one.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-02-14 10:29 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-08 13:07 [Bug fortran/46849] New: [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE burnus at gcc dot gnu.org
2010-12-08 13:08 ` [Bug fortran/46849] " burnus at gcc dot gnu.org
2010-12-08 13:30 ` burnus at gcc dot gnu.org
2010-12-08 13:48 ` janus at gcc dot gnu.org
2010-12-13 21:59 ` janus at gcc dot gnu.org
2010-12-14 8:36 ` burnus at gcc dot gnu.org
2010-12-14 12:13 ` janus at gcc dot gnu.org
2010-12-14 18:31 ` janus at gcc dot gnu.org
2010-12-17 12:32 ` janus at gcc dot gnu.org
2010-12-17 12:34 ` janus at gcc dot gnu.org
2011-02-14 10:30 ` janus 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).