[Bug fortran/46344] New: [OOP] ICE with allocatable CLASS components

[Bug fortran/46344] New: [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

           Summary: [OOP] ICE with allocatable CLASS components
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: janus@gcc.gnu.org


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.

[Bug fortran/46344] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #1 from janus at gcc dot gnu.org 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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

--- Comment #7 from Salvatore Filippone <sfilippone at uniroma2 dot it> 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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344

Jakub Jelinek <jakub at gcc dot gnu.org> 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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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.