From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24807 invoked by alias); 25 Feb 2014 13:44:03 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 24737 invoked by uid 55); 25 Feb 2014 13:43:58 -0000 From: "paul.richard.thomas at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types Date: Tue, 25 Feb 2014 13:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: paul.richard.thomas at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg02534.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 --- Comment #12 from paul.richard.thomas at gmail dot com --- Dear Tobias, I think that I have see the light! In a particularly uninteresting part of our Board Meeting, I took a look at the Doxygen documentation of the compiler. I was trying to figure out how it is possible to get TYPE_SIZE_UNIT and no DECL_SIZE_UNIT..... Right at the beginning of trans-decl.c (gfc_get_symbol_decl) is: 01193 /* Make sure that the vtab for the declared type is completed. */ 01194 if (sym->ts.type == BT_CLASS) 01195 { 01196 gfc_component *c = CLASS_DATA (sym); 01197 if (!c->ts.u.derived->backend_decl) 01198 { 01199 gfc_find_derived_vtab (c->ts.u.derived); 01200 gfc_get_derived_type (sym->ts.u.derived); 01201 } 01202 } I think that the derived type should be built first, followed by the vtable. With the declared type being in a cyclic type definition, one is asking for the size information to be unavailable/incorrect when the vtable is built. I suspect that the ICE is occurring when the vtable is initialized. I suspect that we should have: 01193 /* Make sure that the vtab for the declared type is completed. */ 01194 if (sym->ts.type == BT_CLASS) 01195 { 01196 gfc_component *c = CLASS_DATA (sym); 01197 if (!c->ts.u.derived->backend_decl) 01198 { 01198bis gfc_symbol *s; 01199 gfc_get_derived_type (sym->ts.u.derived); /* Ensure backend_decl is complete. */ 01200 s = gfc_find_derived_vtab (c->ts.u.derived); /* Maybe set backend_decl to NULL_TREE? */ 01200bis gfc_get_symbol_decl (s); /* Build the vtable backend_decl. */ 01201 } 01202 } It'll probably be wrong but I can only get to it tonight. What are you up to? Cheers Paul PS Must update Doxygen documentation on wiki and the bug statistics ---------- Forwarded message ---------- From: pault at gcc dot gnu.org Date: 25 February 2014 10:31 Subject: [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types To: pault@gcc.gnu.org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 --- Comment #11 from Paul Thomas --- A correct version of the patch of comment#6 to varasm.c is: Index: gcc/varasm.c =================================================================== *** gcc/varasm.c (revision 208048) --- gcc/varasm.c (working copy) *************** output_constructor_regular_field (oc_loc *** 4939,4944 **** --- 4939,4946 ---- better be last. */ gcc_assert (!fieldsize || !DECL_CHAIN (local->field)); } + else if (DECL_SIZE_UNIT (local->field) == NULL_TREE) + fieldsize = int_size_in_bytes (TREE_TYPE (local->field)); else fieldsize = tree_to_uhwi (DECL_SIZE_UNIT (local->field)); } Clearly, this is bomb-proof and so regtesting proceeds without problem for gcc and gfortran. It now remains to understand how structure fields can be built with type size information but with the decl comon information missing! ie. it should be possible to render the above unnecessary. Cheers Paul -- You are receiving this mail because: You are on the CC list for the bug.