[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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.
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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=gccview=revrev=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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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=gccview=revrev=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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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=gccview=revrev=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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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 |---
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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.
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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;
}
}
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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.
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
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.
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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=gccview=revrev=163631 Log: 2010-08-29 Janus Weil ja...@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 ja...@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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- 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
