From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11571 invoked by alias); 6 Apr 2004 16:40:18 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11521 invoked by alias); 6 Apr 2004 16:40:09 -0000 Date: Tue, 06 Apr 2004 16:40:00 -0000 Message-ID: <20040406164009.11520.qmail@sources.redhat.com> From: "jsm at polyomino dot org dot uk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040324065726.14711.debian-gcc@lists.debian.org> References: <20040324065726.14711.debian-gcc@lists.debian.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file X-Bugzilla-Reason: CC X-SW-Source: 2004-04/txt/msg00540.txt.bz2 List-Id: ------- Additional Comments From jsm at polyomino dot org dot uk 2004-04-06 16:39 ------- Subject: Re: [3.3 regression] ICE in final.c:2117 when compiling a huge source file On Sun, 4 Apr 2004, roger at eyesopen dot com wrote: > [4] Expand EXPR_WITH_FILE_LOCATION's tree node so that it can store a full > integer for line number, perhaps combining column with other fields or just > increasing the size of this node. I'm a bit confused why its using the > "complexity" field at the moment, and just as confused why we have a complexity > field, why the C front end is using it for C_EXP_ORIGINAL_CODE, and why the > f77 front-end that doesn't even set/use C_EXP_ORIGINAL_CODE tests for it!! I don't know the purpose of having TREE_COMPLEXITY as a general expression field, but I'd like to replace C_EXP_ORIGINAL_CODE with a more robust mechanism keeping track of some parser status (which is what this essentially is - not relevant for code generation, only for warnings) in separate structures for expressions that are passed around by value and don't need allocation and garbage collection. This would also help in fixing bug 11250 (distinguishing parenthesised and nonparenthesised strings), and the constant expressions issues (456, 5675, 14649 at least) where several flags are needed on expressions and types that are irrelevant for code generation and don't need to bulk up trees. At present, for C_EXP_ORIGINAL_CODE to work properly for -Wparentheses warnings, constants derived from folding are artificially wrapped in NON_LVALUE_EXPR so that C_EXP_ORIGINAL_CODE can be set. Whether something is an lvalue is another parser property that can be tracked as a single bit outside the trees rather than allocating a NON_LVALUE_EXPR node, irrelevant for code generation, in various cases. However, the warning for assignments used as truth values is in code shared between C and C++, and uses C_EXP_ORIGINAL_CODE, which complicates getting fix of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711