public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-23 23:36 ` mikael at gcc dot gnu.org
2011-02-24 22:07 ` mikael at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-02-23 23:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #31 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-23 23:08:18 UTC ---
(In reply to comment #25)
> This seems to be a module-loading bug. When reading the specific binding of the
> TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we
> expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' from
> 'mod2'.
>
> My knowledge of the module-reading code is not sufficient to see where stuff
> goes wrong. Maybe someone else can?
This is not a module loading problem I think.
It's true that the two `my_get' functions do conflict in the program namespace.
One does not need to pass by the program namespace to resolve the typebound
call however.
That is, the gfc_typebound_proc.u.specific field should be a gfc_symbol, not a
gfc_symtree.
This way, even if that gfc_symbol is not accessible through a gfc_symtree in
the program namespace, it is loaded anyway (and gets a unique symtree but this
is an implementation detail) because it is needed in the gfc_typebound_proc
struct.
That being said, I suppose there is a reason for it to be a gfc_symtree, and
not a gfc_symbol.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
2011-02-23 23:36 ` [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure mikael at gcc dot gnu.org
@ 2011-02-24 22:07 ` mikael at gcc dot gnu.org
2011-02-25 0:55 ` mikael at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-02-24 22:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #32 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-24 22:04:52 UTC ---
Created attachment 23460
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23460
hack implementing comment 31
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
2011-02-23 23:36 ` [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure mikael at gcc dot gnu.org
2011-02-24 22:07 ` mikael at gcc dot gnu.org
@ 2011-02-25 0:55 ` mikael at gcc dot gnu.org
2011-03-01 16:27 ` mikael at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-02-25 0:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #33 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-24 23:57:24 UTC ---
One should also look at related bugs PR45836 and pr45900.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-02-25 0:55 ` mikael at gcc dot gnu.org
@ 2011-03-01 16:27 ` mikael at gcc dot gnu.org
2011-03-25 20:08 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-03-01 16:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #34 from Mikael Morin <mikael at gcc dot gnu.org> 2011-03-01 16:26:53 UTC ---
The hack in comment 32 compiles correctly comment 24, but rejects the following
variant (with the type-bound call in a subroutine) with:
use mod2
1
Error: Name 'my_get' at (1) is an ambiguous reference to 'my_get' from module
'mod2'
module mod1
type :: t1
contains
procedure, nopass :: get => my_get
end type
contains
subroutine my_get()
print *,"my_get (mod1)"
end subroutine
end module
module mod2
contains
subroutine my_get() ! must have the same name as the function in mod1
print *,"my_get (mod2)"
end subroutine
end module
use mod2
use mod1 ! order of use statements is important
type(t1) :: a
call call_get
contains
subroutine call_get
call a%get()
end subroutine call_get
end
The reason is that the following code in resolve_call reloads the procedure
symbol from the current namespace. This could be disabled with a flag, but it
would just make the hack uglier.
if (csym && gfc_current_ns->parent && csym->ns != gfc_current_ns)
{
gfc_symtree *st;
gfc_find_sym_tree (csym->name, gfc_current_ns, 1, &st);
sym = st ? st->n.sym : NULL;
if (sym && csym != sym
&& sym->ns == gfc_current_ns
&& sym->attr.flavor == FL_PROCEDURE
&& sym->attr.contained)
{
sym->refs++;
if (csym->attr.generic)
c->symtree->n.sym = sym;
else
c->symtree = st;
csym = c->symtree->n.sym;
}
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-03-01 16:27 ` mikael at gcc dot gnu.org
@ 2011-03-25 20:08 ` jakub at gcc dot gnu.org
2011-04-28 16:51 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-03-25 20:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.0 |4.6.1
--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:53:08 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-03-25 20:08 ` jakub at gcc dot gnu.org
@ 2011-04-28 16:51 ` rguenth at gcc dot gnu.org
2013-01-06 15:50 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-04-28 16:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.1 |---
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2011-04-28 16:51 ` rguenth at gcc dot gnu.org
@ 2013-01-06 15:50 ` mikael at gcc dot gnu.org
2013-01-08 19:43 ` mikael at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2013-01-06 15:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #36 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-06 15:50:19 UTC ---
Author: mikael
Date: Sun Jan 6 15:50:09 2013
New Revision: 194949
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949
Log:
PR fortran/42769
PR fortran/45836
PR fortran/45900
* module.c (read_module): Don't reuse local symtree if the associated
symbol isn't exactly the one wanted. Don't reuse local symtree if it is
ambiguous.
* resolve.c (resolve_call): Use symtree's name instead of symbol's to
lookup the symtree.
PR fortran/42769
PR fortran/45836
PR fortran/45900
* gfortran.dg/use_23.f90: New test.
* gfortran.dg/use_24.f90: New test.
* gfortran.dg/use_25.f90: New test.
* gfortran.dg/use_26.f90: New test.
* gfortran.dg/use_27.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/use_23.f90
trunk/gcc/testsuite/gfortran.dg/use_24.f90
trunk/gcc/testsuite/gfortran.dg/use_25.f90
trunk/gcc/testsuite/gfortran.dg/use_26.f90
trunk/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2013-01-06 15:50 ` mikael at gcc dot gnu.org
@ 2013-01-08 19:43 ` mikael at gcc dot gnu.org
2013-01-08 20:02 ` mikael at gcc dot gnu.org
2013-01-09 14:29 ` mikael at gcc dot gnu.org
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2013-01-08 19:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #37 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-08 19:42:47 UTC ---
Author: mikael
Date: Tue Jan 8 19:42:38 2013
New Revision: 195031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031
Log:
PR fortran/42769
PR fortran/45836
PR fortran/45900
* module.c (read_module): Don't reuse local symtree if the associated
symbol isn't exactly the one wanted. Don't reuse local symtree if it is
ambiguous.
* resolve.c (resolve_call): Use symtree's name instead of symbol's to
lookup the symtree.
PR fortran/42769
PR fortran/45836
PR fortran/45900
* gfortran.dg/use_23.f90: New test.
* gfortran.dg/use_24.f90: New test.
* gfortran.dg/use_25.f90: New test.
* gfortran.dg/use_26.f90: New test.
* gfortran.dg/use_27.f90: New test.
Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/module.c
branches/gcc-4_7-branch/gcc/fortran/resolve.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2013-01-08 19:43 ` mikael at gcc dot gnu.org
@ 2013-01-08 20:02 ` mikael at gcc dot gnu.org
2013-01-09 14:29 ` mikael at gcc dot gnu.org
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2013-01-08 20:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #38 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-08 20:02:00 UTC ---
Author: mikael
Date: Tue Jan 8 20:01:49 2013
New Revision: 195032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032
Log:
PR fortran/42769
PR fortran/45836
PR fortran/45900
* module.c (read_module): Don't reuse local symtree if the associated
symbol isn't exactly the one wanted. Don't reuse local symtree if it is
ambiguous.
* resolve.c (resolve_call): Use symtree's name instead of symbol's to
lookup the symtree.
PR fortran/42769
PR fortran/45836
PR fortran/45900
* gfortran.dg/use_23.f90: New test.
* gfortran.dg/use_24.f90: New test.
* gfortran.dg/use_25.f90: New test.
* gfortran.dg/use_26.f90: New test.
* gfortran.dg/use_27.f90: New test.
Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/module.c
branches/gcc-4_6-branch/gcc/fortran/resolve.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2013-01-08 20:02 ` mikael at gcc dot gnu.org
@ 2013-01-09 14:29 ` mikael at gcc dot gnu.org
9 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2013-01-09 14:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.6.4
--- Comment #39 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-09 14:29:31 UTC ---
Fixed for 4.6.4 4.7.3 4.8.0.
Thanks for the bug report.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
` (6 preceding siblings ...)
2010-08-29 21:30 ` janus at gcc dot gnu dot org
@ 2010-08-29 21:36 ` janus at gcc dot gnu dot org
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-29 21:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from janus at gcc dot gnu dot org 2010-08-29 21:36 -------
r163631 fixes comment #27, but the other stuff still fails:
1) the original test case (comment #1, ICE)
2) the reduced version (comment #8, ICE)
3) the variant in comment #24 (wrong-code)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
` (5 preceding siblings ...)
2010-08-23 13:33 ` janus at gcc dot gnu dot org
@ 2010-08-29 21:30 ` janus at gcc dot gnu dot org
2010-08-29 21:36 ` janus at gcc dot gnu dot org
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-29 21:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from janus at gcc dot gnu dot org 2010-08-29 21:29 -------
Subject: Bug 42769
Author: janus
Date: Sun Aug 29 21:29:38 2010
New Revision: 163631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163631
Log:
2010-08-29 Janus Weil <janus@gcc.gnu.org>
PR fortran/42769
* resolve.c (resolve_structure_cons): For derived types, make sure the
type has been resolved.
(resolve_typebound_procedures): Make sure the vtab has been generated.
2010-08-29 Janus Weil <janus@gcc.gnu.org>
PR fortran/42769
* gfortran.dg/dynamic_dispatch_11.f03: New.
Added:
trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_11.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
` (4 preceding siblings ...)
2010-08-23 13:26 ` janus at gcc dot gnu dot org
@ 2010-08-23 13:33 ` janus at gcc dot gnu dot org
2010-08-29 21:30 ` janus at gcc dot gnu dot org
2010-08-29 21:36 ` janus at gcc dot gnu dot org
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-23 13:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from janus at gcc dot gnu dot org 2010-08-23 13:32 -------
Comment #27 can be fixed by:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 163468)
+++ gcc/fortran/resolve.c (working copy)
@@ -10937,10 +10937,12 @@ error:
stree->n.tb->error = 1;
}
+
static gfc_try
resolve_typebound_procedures (gfc_symbol* derived)
{
int op;
+ gfc_symbol *vtab;
if (!derived->f2k_derived || !derived->f2k_derived->tb_sym_root)
return SUCCESS;
@@ -10948,6 +10950,9 @@ resolve_typebound_procedures (gfc_symbol* derived)
resolve_bindings_derived = derived;
resolve_bindings_result = SUCCESS;
+ /* Make sure the vtab has been generated. */
+ vtab = gfc_find_derived_vtab (derived);
+
if (derived->f2k_derived->tb_sym_root)
gfc_traverse_symtree (derived->f2k_derived->tb_sym_root,
&resolve_typebound_procedure);
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-01-16 21:04:41 |2010-08-23 13:32:36
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
` (3 preceding siblings ...)
2010-08-13 17:29 ` janus at gcc dot gnu dot org
@ 2010-08-23 13:26 ` janus at gcc dot gnu dot org
2010-08-23 13:33 ` janus at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-23 13:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from janus at gcc dot gnu dot org 2010-08-23 13:25 -------
(In reply to comment #24)
> Here is a somewhat modified version of comment #14, which compiles but produces
> wrong code:
The example in comment #24 contains a statically-resolved TBP call (the pass
object is non-polymorphic). One can construct an analogous version with a
polymorphic TBP call, which also fails:
> module mod1
> type :: t1
> contains
> procedure, nopass :: get => my_get
> end type
> contains
> subroutine my_get()
> print *,"my_get (mod1)"
> end subroutine
> end module
>
> module mod2
> contains
> subroutine my_get() ! must have the same name as the function in mod1
> print *,"my_get (mod2)"
> end subroutine
> end module
use mod2
use mod1 ! order of use statements is important
class(t1),allocatable :: a
allocate(a)
call a%get()
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
` (2 preceding siblings ...)
2010-06-11 22:16 ` janus at gcc dot gnu dot org
@ 2010-08-13 17:29 ` janus at gcc dot gnu dot org
2010-08-23 13:26 ` janus at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 17:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from janus at gcc dot gnu dot org 2010-08-13 17:28 -------
cf. also PR45271
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
2010-05-14 11:53 ` [Bug fortran/42769] [OOP] " janus at gcc dot gnu dot org
2010-06-11 21:33 ` janus at gcc dot gnu dot org
@ 2010-06-11 22:16 ` janus at gcc dot gnu dot org
2010-08-13 17:29 ` janus at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-06-11 22:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from janus at gcc dot gnu dot org 2010-06-11 22:16 -------
This seems to be a module-loading bug. When reading the specific binding of the
TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we
expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' from
'mod2'.
My knowledge of the module-reading code is not sufficient to see where stuff
goes wrong. Maybe someone else can?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
2010-05-14 11:53 ` [Bug fortran/42769] [OOP] " janus at gcc dot gnu dot org
@ 2010-06-11 21:33 ` janus at gcc dot gnu dot org
2010-06-11 22:16 ` janus at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-06-11 21:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from janus at gcc dot gnu dot org 2010-06-11 21:33 -------
Here is a somewhat modified version of comment #14, which compiles but produces
wrong code:
module mod1
type :: t1
contains
procedure, nopass :: get => my_get
end type
contains
subroutine my_get()
print *,"my_get (mod1)"
end subroutine
end module
module mod2
contains
subroutine my_get() ! must have the same name as the function in mod1
print *,"my_get (mod2)"
end subroutine
end module
use mod2
use mod1 ! order of use statements is important
type(t1) :: a
call a%get()
end
Output is "my_get (mod2)" while it should be "my_get (mod1)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
@ 2010-05-14 11:53 ` janus at gcc dot gnu dot org
2010-06-11 21:33 ` janus at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-05-14 11:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from janus at gcc dot gnu dot org 2010-05-14 11:53 -------
(In reply to comment #22)
> Janus, is there something left to do here?
Yes, sure. The ICE has not been fixed yet. With 4.6 trunk (r159368) I still get
the same ICE on comment #8/#14:
internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:10304
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|ICE in |[OOP] ICE in
|resolve_typebound_procedure |resolve_typebound_procedure
Target Milestone|4.5.1 |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-01-09 14:29 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-42769-4@http.gcc.gnu.org/bugzilla/>
2011-02-23 23:36 ` [Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure mikael at gcc dot gnu.org
2011-02-24 22:07 ` mikael at gcc dot gnu.org
2011-02-25 0:55 ` mikael at gcc dot gnu.org
2011-03-01 16:27 ` mikael at gcc dot gnu.org
2011-03-25 20:08 ` jakub at gcc dot gnu.org
2011-04-28 16:51 ` rguenth at gcc dot gnu.org
2013-01-06 15:50 ` mikael at gcc dot gnu.org
2013-01-08 19:43 ` mikael at gcc dot gnu.org
2013-01-08 20:02 ` mikael at gcc dot gnu.org
2013-01-09 14:29 ` mikael at gcc dot gnu.org
2010-01-16 17:00 [Bug fortran/42769] New: " sfilippone at uniroma2 dot it
2010-05-14 11:53 ` [Bug fortran/42769] [OOP] " janus at gcc dot gnu dot org
2010-06-11 21:33 ` janus at gcc dot gnu dot org
2010-06-11 22:16 ` janus at gcc dot gnu dot org
2010-08-13 17:29 ` janus at gcc dot gnu dot org
2010-08-23 13:26 ` janus at gcc dot gnu dot org
2010-08-23 13:33 ` janus at gcc dot gnu dot org
2010-08-29 21:30 ` janus at gcc dot gnu dot org
2010-08-29 21:36 ` janus at gcc dot gnu dot 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).