* [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