Bug 46344 - [4.6 Regression] [OOP] ICE with allocatable CLASS components
Summary: [4.6 Regression] [OOP] ICE with allocatable CLASS components
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P4 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords: ice-on-valid-code
: 46345 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-11-07 12:55 UTC by janus
Modified: 2010-11-09 10:35 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.5.1
Known to fail: 4.6.0
Last reconfirmed: 2010-11-07 20:41:31


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2010-11-07 12:55:10 UTC
Test case:


module mld_d_prec_type

  type mld_d_base_solver_type
  end type mld_d_base_solver_type

  type  mld_d_base_smoother_type
    class(mld_d_base_solver_type), allocatable :: sv
  end type mld_d_base_smoother_type

  type mld_donelev_type
    class(mld_d_base_smoother_type), allocatable :: sm
  end type mld_donelev_type

end module mld_d_prec_type

program ppde
  use mld_d_prec_type
  implicit none

  type(mld_donelev_type), allocatable :: precv(:) 

  allocate(precv(1))

end program ppde


This produces an ICE (segfault) with current trunk. Reported by Salvatore Fillipone.
Comment 1 janus 2010-11-07 12:58:32 UTC
Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000576077 in structure_alloc_comps (der_type=0x1914d40, decl=0x7ffff6ba0300, dest=0x0, rank=0, purpose=1)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6322
6322                  comp = fold_build3_loc (input_location, COMPONENT_REF,
(gdb) bt
#0  0x0000000000576077 in structure_alloc_comps (der_type=0x1914d40, decl=0x7ffff6ba0300, dest=0x0, rank=0, purpose=1)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6322
#1  0x00000000005766fd in gfc_deallocate_alloc_comp (der_type=0x1914d40, decl=0x7ffff6ba0300, rank=0)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6435
#2  0x0000000000561fdc in gfc_deallocate_scalar_with_status (pointer=0x7ffff6b99a00, status=0x0, can_fail=1 '\001', expr=0x0, ts=...)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans.c:1005
#3  0x00000000005760f7 in structure_alloc_comps (der_type=0x1915310, decl=0x7ffff7f09828, dest=0x0, rank=1, purpose=1)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6325
#4  0x0000000000575c8a in structure_alloc_comps (der_type=0x1915310, decl=0x7ffff7fcb500, dest=0x0, rank=1, purpose=1)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6251
#5  0x00000000005766fd in gfc_deallocate_alloc_comp (der_type=0x1915310, decl=0x7ffff7fcb500, rank=1)
    at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6435
#6  0x0000000000576cba in gfc_trans_deferred_array (sym=0x1917610, block=0x7fffffffde10) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6564
#7  0x000000000058c6cc in gfc_trans_deferred_vars (proc_sym=0x1912340, block=0x7fffffffde10) at /home/jweil/gcc46/trunk/gcc/fortran/trans-decl.c:3372
#8  0x00000000005913d0 in gfc_generate_function_code (ns=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/trans-decl.c:4703
#9  0x00000000005630f7 in gfc_generate_code (ns=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/trans.c:1510
#10 0x000000000050c989 in translate_all_program_units (gfc_global_ns_list=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4243
#11 0x000000000050cf4a in gfc_parse_file () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4443
#12 0x0000000000551daf in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/trunk/gcc/fortran/f95-lang.c:250
#13 0x0000000000a307c5 in compile_file () at /home/jweil/gcc46/trunk/gcc/toplev.c:919
#14 0x0000000000a32ceb in do_compile () at /home/jweil/gcc46/trunk/gcc/toplev.c:2359
#15 0x0000000000a32e17 in toplev_main (argc=2, argv=0x7fffffffe228) at /home/jweil/gcc46/trunk/gcc/toplev.c:2419
#16 0x00000000005e529c in main (argc=2, argv=0x7fffffffe228) at /home/jweil/gcc46/trunk/gcc/main.c:36
Comment 2 janus 2010-11-07 13:04:49 UTC
*** Bug 46345 has been marked as a duplicate of this bug. ***
Comment 3 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 [details]
Comment 4 janus 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.)
Comment 5 janus 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.
Comment 6 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 0x100003072: pointer being freed was not allocated
Comment 7 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 0x100003072: 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
Comment 8 janus 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).
Comment 9 janus 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.
Comment 10 janus 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  <janus@gcc.gnu.org>

	PR fortran/46344
	* trans-types.c (gfc_copy_dt_decls_ifequal): Handle CLASS components.

2010-11-08  Janus Weil  <janus@gcc.gnu.org>

	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
Comment 11 janus 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.
Comment 12 janus 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!
Comment 13 janus 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  <janus@gcc.gnu.org>

	PR fortran/46344
	* decl.c (build_struct): Build vtab immediately if derived type
	has already been declared.

2010-11-08  Janus Weil  <janus@gcc.gnu.org>

	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
Comment 14 janus 2010-11-08 22:46:09 UTC
r166458 fixes comment #11 (by building the vtab early).
Comment 15 janus 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.