[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2016-11-16 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-17 Thread janus at gcc dot gnu dot org
--- Comment #9 from janus at gcc dot gnu dot org 2010-05-17 20:05 --- Fixed with r159511. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-17 Thread janus at gcc dot gnu dot org
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 19:59 --- Subject: Bug 43990 Author: janus Date: Mon May 17 19:58:48 2010 New Revision: 159511 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159511 Log: 2010-05-17 Janus Weil PR fortran/43990 * tran

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-17 Thread janus at gcc dot gnu dot org
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 17:41 --- (In reply to comment #6) > but it does not fix PR43895 (see comments #3 and #4). ... which I take as an indication that the two are indeed not so much related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-17 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-17 17:09 --- The patch in comment #5 fixes the ICE without side effects (AFAICT!-), but it does not fix PR43895 (see comments #3 and #4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-16 Thread janus at gcc dot gnu dot org
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-16 22:11 --- The ICE is fixed by removing this unneeded (and buggy) piece of code: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 15944

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-06 Thread burnus at gcc dot gnu dot org
--- Comment #4 from burnus at gcc dot gnu dot org 2010-05-06 16:37 --- (In reply to comment #3) > See also PR 43895 As I feared there: There seems to be an inconsistency with CLASS with POINTER or ALLOCATABLE attribute: Is "class.$DATA" or "class" the pointer variable. If one adds "b =

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-06 Thread burnus at gcc dot gnu dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-06 16:27 --- See also PR 43895 - the issue seems to be similar though one does not have an except that there one has no static-memory initialization. [I might also be completely off.] -- http://gcc.gnu.org/bugzilla/show_bug.c

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-05 Thread burnus at gcc dot gnu dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2010-05-05 14:12 --- The problem seems to be the initialization at gfc_conv_structure (init = 1) in trans-expr.c: We have: logical :: l = .true. class(t),pointer :: cp => null() and thus: (gdb) p expr->ts.u.derived->components

[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995

2010-05-05 Thread burnus at gcc dot gnu dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-05 12:41 --- if ((local->field != NULL_TREE || local->index != NULL_TREE) && fieldpos != local->total_bytes) { gcc_assert (fieldpos >= local->total_bytes); Debugging shows: field != NULL_TREE, index == NULL_TR