[Bug middle-end/14711] [3.3 regression] ICE in final.c:2117 when compiling a huge source file

["jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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