[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from janus at gcc dot gnu.org 2010-11-09 10:35:03 UTC --- I'm not been able to find any more failing test cases along the lines of comment #11. Closing as fixed.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #14 from janus at gcc dot gnu.org 2010-11-08 22:46:09 UTC --- r166458 fixes comment #11 (by building the vtab early).
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #13 from janus at gcc dot gnu.org 2010-11-08 22:42:41 UTC --- Author: janus Date: Mon Nov 8 22:42:34 2010 New Revision: 166458 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166458 Log: 2010-11-08 Janus Weil PR fortran/46344 * decl.c (build_struct): Build vtab immediately if derived type has already been declared. 2010-11-08 Janus Weil PR fortran/46344 * gfortran.dg/class_28.f03: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_28.f03
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #12 from janus at gcc dot gnu.org 2010-11-08 14:39:01 UTC --- (In reply to comment #11) > The error seems to be sensitive to the first letter of the type(t1) variable. > All names starting with 'w'-'z' fail, others seem to work. Also the error > disappears when adding "implicit none", so it seems to be connected to > implicit > typing. After some more research I came to the conclusion that it's rather a resolution problem: Sometimes symbols for class containers and vtabs are generated at resolution stage. If this happens while traversing a namespace's symbol tree, symbols are being added and the tree is rearranged, so that the traversing routine may miss some symbols! This is also the reason why this error occurs so randomly: It depends on how the tree is being rearranged and whether we're lucky enough to still resolve all symbols!
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #11 from janus at gcc dot gnu.org 2010-11-08 09:20:48 UTC --- r166430 fixes the test cases in comment #0 and #4 and the one in PR 46345. However, the problem in comment #5 persists. Reduced test case: module m type t1 end type type t2 class(t1), allocatable :: c end type type(t1) :: w end module m end module m 1 Internal Error at (1): write_symbol(): bad module symbol 'w' The error seems to be sensitive to the first letter of the type(t1) variable. All names starting with 'w'-'z' fail, others seem to work. Also the error disappears when adding "implicit none", so it seems to be connected to implicit typing.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #10 from janus at gcc dot gnu.org 2010-11-08 09:04:03 UTC --- Author: janus Date: Mon Nov 8 09:03:50 2010 New Revision: 166430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166430 Log: 2010-11-08 Janus Weil PR fortran/46344 * trans-types.c (gfc_copy_dt_decls_ifequal): Handle CLASS components. 2010-11-08 Janus Weil PR fortran/46344 * gfortran.dg/class_28.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_28.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #9 from janus at gcc dot gnu.org 2010-11-07 21:12:22 UTC --- (In reply to comment #8) > The ICE can be fixed with the following patch: Here is a better patch which has the same effect: Index: gcc/fortran/trans-types.c === --- gcc/fortran/trans-types.c(revision 166419) +++ gcc/fortran/trans-types.c(working copy) @@ -1936,10 +1936,12 @@ gfc_copy_dt_decls_ifequal (gfc_symbol *from, gfc_s for (; to_cm; to_cm = to_cm->next, from_cm = from_cm->next) { to_cm->backend_decl = from_cm->backend_decl; - if ((!from_cm->attr.pointer || from_gsym) - && from_cm->ts.type == BT_DERIVED) + if (from_cm->ts.type == BT_DERIVED + && (!from_cm->attr.pointer || from_gsym)) gfc_get_derived_type (to_cm->ts.u.derived); - + else if (from_cm->ts.type == BT_CLASS + && (!CLASS_DATA (from_cm)->attr.class_pointer || from_gsym)) +gfc_get_derived_type (to_cm->ts.u.derived); else if (from_cm->ts.type == BT_CHARACTER) to_cm->ts.u.cl->backend_decl = from_cm->ts.u.cl->backend_decl; } In fact this one pretty much qualifies as obvious, once the location of the problem has been identified. It's one of those instances where we do something for BT_DERIVED, but fail to do the analogous thing for BT_CLASS. I will commit after regtesting.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.07 20:41:31 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #8 from janus at gcc dot gnu.org 2010-11-07 20:41:31 UTC --- The ICE can be fixed with the following patch: Index: gcc/fortran/trans-array.c === --- gcc/fortran/trans-array.c (revision 166419) +++ gcc/fortran/trans-array.c (working copy) @@ -6278,6 +6278,9 @@ structure_alloc_comps (gfc_symbol * der_type, tree cdecl = c->backend_decl; ctype = TREE_TYPE (cdecl); + if (c->ts.type == BT_CLASS && c->ts.u.derived->backend_decl == NULL) + gfc_get_derived_type (c->ts.u.derived); + switch (purpose) { case DEALLOCATE_ALLOC_COMP: With this the test case from PR46345 gives the output: Check 0: F (which apparently is the expected result).
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #7 from Salvatore Filippone 2010-11-07 14:58:40 UTC --- (In reply to comment #6) > Revision 162456 compiles the tests, but not revision 166102. When compiled, > the > executable for pr46345 gives > > Check 0: T > a.out(84352) malloc: *** error for object 0x13072: pointer being freed was > not allocated ...which is the original problem for which I was trying to open a PR, a wrong allocation status for a scalar component. Salvatore
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #6 from Dominique d'Humieres 2010-11-07 13:39:37 UTC --- Revision 162456 compiles the tests, but not revision 166102. When compiled, the executable for pr46345 gives Check 0: T a.out(84352) malloc: *** error for object 0x13072: pointer being freed was not allocated
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #5 from janus at gcc dot gnu.org 2010-11-07 13:22:07 UTC --- (In reply to comment #4) > Here's a variant: Side remark: In comment #4, if I change the name of 'sm' to 'y', I get: end module m 1 Internal Error at (1): write_symbol(): bad module symbol 'y' ... which is *very* strange to say the least.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #4 from janus at gcc dot gnu.org 2010-11-07 13:16:29 UTC --- Here's a variant: module m type t1 end type type t2 class(t1), allocatable :: cc end type class(t2), allocatable :: sm end module m program p use m implicit none type(t2), allocatable :: x(:) allocate(x(1)) end program p (Same ICE.)
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #3 from Tobias Burnus 2010-11-07 13:07:35 UTC --- (In reply to comment #2) > *** Bug 46345 has been marked as a duplicate of this bug. *** That PR contains a longer test case: attachment 22307
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 janus at gcc dot gnu.org changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #2 from janus at gcc dot gnu.org 2010-11-07 13:04:49 UTC --- *** Bug 46345 has been marked as a duplicate of this bug. ***