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

2010-11-09 Thread 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.

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

2010-11-08 Thread 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=gccview=revrev=166430
Log:
2010-11-08  Janus Weil  ja...@gcc.gnu.org

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

2010-11-08  Janus Weil  ja...@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

2010-11-08 Thread 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

2010-11-08 Thread 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

2010-11-08 Thread 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

2010-11-08 Thread 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=gccview=revrev=166458
Log:
2010-11-08  Janus Weil  ja...@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  ja...@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

2010-11-08 Thread 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

2010-11-07 Thread 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

2010-11-07 Thread 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

2010-11-07 Thread 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

2010-11-07 Thread 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

2010-11-07 Thread 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 0x13072: pointer being freed was
not allocated

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

2010-11-07 Thread 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 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

2010-11-07 Thread 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

2010-11-07 Thread 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.