[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #7 from janus at gcc dot gnu.org 2010-12-29 16:14:20 UTC --- Author: janus Date: Wed Dec 29 16:14:11 2010 New Revision: 168322 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168322 Log: 2010-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/46838 * expr.c (gfc_default_initializer): Handle allocatable CLASS components. 2010-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/46838 * gfortran.dg/alloc_comp_class_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #8 from janus at gcc dot gnu.org 2010-12-29 16:30:47 UTC --- r168322 fixes the original test case as well as the reduction in comment #1. ToDo: The array version (cf. comment #1) still ICEs: implicit none type indx_map end type type desc_type class(indx_map), allocatable :: indxmap(:) end type type(desc_type) :: desc if (allocated(desc%indxmap)) call abort() end internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:144
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from janus at gcc dot gnu.org 2010-12-29 17:04:02 UTC --- (In reply to comment #8) ToDo: The array version (cf. comment #1) still ICEs: This is now being tracked by PR 43969, therefore I'm closing this one.
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.12.28 10:52:23
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Summary|[OOP] Wrong allocation |[OOP] Initialization of
|status for polymorphic |polymorphic allocatable
|component INTENT(OUT) dummy |components
Ever Confirmed|0 |1
--- Comment #4 from janus at gcc dot gnu.org 2010-12-28 10:52:23 UTC ---
(In reply to comment #2)
The default initializer is obtained via expr.c's gfc_default_initializer.
Indeed this is the place where things go wrong. Here's a patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 168277)
+++ gcc/fortran/expr.c(working copy)
@@ -3648,7 +3648,8 @@ gfc_default_initializer (gfc_typespec *ts)
/* See if we have a default initializer in this, but not in nested
types (otherwise we could use gfc_has_default_initializer()). */
for (comp = ts-u.derived-components; comp; comp = comp-next)
-if (comp-initializer || comp-attr.allocatable)
+if (comp-initializer || comp-attr.allocatable
+|| (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
break;
if (!comp)
@@ -3664,8 +3665,9 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp-initializer)
ctor-expr = gfc_copy_expr (comp-initializer);
-
- if (comp-attr.allocatable)
+ else if (comp-attr.allocatable
+ || (comp-ts.type == BT_CLASS
+CLASS_DATA (comp)-attr.allocatable))
{
ctor-expr = gfc_get_expr ();
ctor-expr-expr_type = EXPR_NULL;
This fixes the test case in comment #1. However, I was not able to see a
failure with the test case in comment #0. Salvatore, can you check whether the
patch cures your troubles?
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #5 from janus at gcc dot gnu.org 2010-12-28 12:51:22 UTC ---
(In reply to comment #4)
Here's a patch:
The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1.f90
etc), but the following version regtests cleanly:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 168293)
+++ gcc/fortran/expr.c(working copy)
@@ -3648,7 +3648,8 @@ gfc_default_initializer (gfc_typespec *ts)
/* See if we have a default initializer in this, but not in nested
types (otherwise we could use gfc_has_default_initializer()). */
for (comp = ts-u.derived-components; comp; comp = comp-next)
-if (comp-initializer || comp-attr.allocatable)
+if (comp-initializer || comp-attr.allocatable
+|| (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
break;
if (!comp)
@@ -3665,7 +3666,8 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp-initializer)
ctor-expr = gfc_copy_expr (comp-initializer);
- if (comp-attr.allocatable)
+ if (comp-attr.allocatable
+ || (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
{
ctor-expr = gfc_get_expr ();
ctor-expr-expr_type = EXPR_NULL;
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-28 13:40:52 UTC --- (In reply to comment #5) (In reply to comment #4) Here's a patch: The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1.f90 etc), but the following version regtests cleanly: For me, it cures the reduced test case (bug28.f90) in comment #0, so it's definitely a step in the right direction. Unfortunately in the full application I still get this: [localhost:15473] Signal: Segmentation fault (11) [localhost:15473] Signal code: Address not mapped (1) [localhost:15473] Failing at address: 0x1344133b [localhost:15472] [ 0] /lib64/libpthread.so.0(+0xf4a0) [0x7fae89b8b4a0] [localhost:15472] [ 1] /lib64/libc.so.6(cfree+0x1c) [0x7fae898782dc] [localhost:15472] [ 2] ./ppde(__copy_psb_gen_block_map_mod_psb_gen_block_map_+0x143) [0x4c45b3] [localhost:15472] [ 3] ./ppde(psb_cdcpy_+0x700) [0x4bf850] [localhost:15472] [ 4] ./ppde(psb_dcdbldext_+0x7e2) [0x4b2762] [localhost:15472] [ 5] ./ppde() [0x41985f] [localhost:15472] [ 6] ./ppde() [0x41c6dd] [localhost:15472] [ 7] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fae8981cc5d] [localhost:15472] [ 8] ./ppde() [0x418ef9] [localhost:15472] *** End of error message *** I suppose this means that the original test case did not catch all there was; I guess it would be best to declare this fixed and open a new one, as soon as I have time to get a new reduced test case.
