From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24776 invoked by alias); 31 Jan 2003 18:56:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24751 invoked by uid 71); 31 Jan 2003 18:56:00 -0000 Date: Fri, 31 Jan 2003 18:56:00 -0000 Message-ID: <20030131185600.24750.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Andrew Haley Subject: java/8457: [3.2/3.3 regression] ICE in generate_bytecode_insns, at java/jcf-write.c:1850 Reply-To: Andrew Haley X-SW-Source: 2003-01/txt/msg01792.txt.bz2 List-Id: The following reply was made to PR java/8457; it has been noted by GNATS. From: Andrew Haley To: gcc-gnats@gcc.gnu.org Cc: Subject: java/8457: [3.2/3.3 regression] ICE in generate_bytecode_insns, at java/jcf-write.c:1850 Date: Fri, 31 Jan 2003 18:48:43 +0000 (GMT) It seems that when we expand constructors of anonymous innter classes we generate access methods that we fail to expand, and later code generation explodes. Fix the fault by making another pass over all the classes and expanding the newly created methods. This doesn't completely fix the test case, as there are more inner class bugs, but it's better. No regressions on i686-RH8. Andrew. 2003-01-31 Andrew Haley * parse.y (java_expand_classes): Scan the whole class list looking for access methods that haven't yet been expanded. Index: parse.y =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v retrieving revision 1.417 diff -p -2 -c -r1.417 parse.y *** parse.y 14 Jan 2003 13:31:11 -0000 1.417 --- parse.y 31 Jan 2003 17:23:06 -0000 *************** java_expand_classes (void) *** 8877,8880 **** --- 8877,8939 ---- } + /* Expanding the constructors of anonymous classes generates access + methods. Scan all the methods looking for null DECL_RESULTs -- + this will be the case if a method hasn't been expanded. */ + for (cur_ctxp = ctxp_for_generation; cur_ctxp; cur_ctxp = cur_ctxp->next) + { + tree current; + ctxp = cur_ctxp; + for (current = ctxp->class_list; current; current = TREE_CHAIN (current)) + { + tree d; + current_class = TREE_TYPE (current); + for (d = TYPE_METHODS (current_class); d; d = TREE_CHAIN (d)) + { + if (DECL_RESULT (d) == NULL_TREE) + { + restore_line_number_status (1); + java_complete_expand_method (d); + restore_line_number_status (0); + } + } + } + } + + /* ??? Instead of all this we could iterate around the list of + classes until there were no more un-expanded methods. It would + take a little longer -- one pass over the whole list of methods + -- but it would be simpler. Like this: */ + #if 0 + { + int something_changed; + + do + { + something_changed = 0; + for (cur_ctxp = ctxp_for_generation; cur_ctxp; cur_ctxp = cur_ctxp->next) + { + tree current; + ctxp = cur_ctxp; + for (current = ctxp->class_list; current; current = TREE_CHAIN (current)) + { + tree d; + current_class = TREE_TYPE (current); + for (d = TYPE_METHODS (current_class); d; d = TREE_CHAIN (d)) + { + if (DECL_RESULT (d) == NULL_TREE) + { + something_changed = 1; + restore_line_number_status (1); + java_complete_expand_method (d); + restore_line_number_status (0); + } + } + } + } + } + while (something_changed); + } + #endif + /* If we've found error at that stage, don't try to generate anything, unless we're emitting xrefs or checking the syntax only