This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/14765] [3.3/3.4/3.5 Regression] [tree-ssa] ice-on-invalid-code, ICE while compiling ({}) expression
- From: "jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Jun 2004 22:13:35 -0000
- Subject: [Bug tree-optimization/14765] [3.3/3.4/3.5 Regression] [tree-ssa] ice-on-invalid-code, ICE while compiling ({}) expression
- References: <20040328225212.14765.belyshev@lubercy.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From jsm at polyomino dot org dot uk 2004-06-06 22:13 -------
Subject: Re: [3.3/3.4/3.5 Regression] [tree-ssa]
ice-on-invalid-code, ICE while compiling ({}) expression
The following patch looks from some tests of patched cc1 like it will fix
this particular issue, but it needs full tests - on both mainline and 3.4
branch, given they show the problem in different places. I'll do the
requisite four bootstraps and testsuite runs tomorrow.
It's not however a general fix of all such issues, as the last_expr_type
mechanism seems a fragile kludge and other cases fail to get detected as
not ending with an expression statement (and then on mainline fail in
gimplification). For example,
void f (void) { int a = ({ while (1) 2; }); }
(ICE on mainline only; regression from 2.95 which detected this case) -
last_expr_type is reset after if statements, but not while statements.
Things could probably be done more cleanly and easily if the C front end
generated GENERIC (and the types of the expressions used for statements
would be kept up so that the type of a statement expression follows
immediately from that of the COMPOUND_EXPR for the contained compound
statement, while the type for one used as a block not in a statement
expression would be set to void). If that's not done in time for 3.5/4.0
then we can look at local fixes for all the cases where last_expr_type
isn't reset.
2004-06-06 Joseph S. Myers <jsm@polyomino.org.uk>
PR c/14765
* c-parse.in (compstmt_primary_start): Set last_expr_type to
NULL_TREE.
2004-06-06 Joseph S. Myers <jsm@polyomino.org.uk>
PR c/14765
* gcc.dg/pr14765-1.c: New test.
diff -rupN gcc.orig/c-parse.in gcc/c-parse.in
--- gcc.orig/c-parse.in 2004-02-08 20:52:50.000000000 +0000
+++ gcc/c-parse.in 2004-06-06 21:40:00.000000000 +0000
@@ -2161,6 +2161,7 @@ compstmt_primary_start:
keep_next_level ();
compstmt_count++;
$$ = add_stmt (build_stmt (COMPOUND_STMT, last_tree));
+ last_expr_type = NULL_TREE;
}
;
diff -rupN gcc.orig/testsuite/gcc.dg/pr14765-1.c gcc/testsuite/gcc.dg/pr14765-1.c
--- gcc.orig/testsuite/gcc.dg/pr14765-1.c 1970-01-01 00:00:00.000000000 +0000
+++ gcc/testsuite/gcc.dg/pr14765-1.c 2004-06-06 21:43:14.000000000 +0000
@@ -0,0 +1,11 @@
+/* Empty statement expressions should get void type. Bug 14765 from
+ Serge Belyshev <belyshev@lubercy.com>. */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int a;
+void fun ()
+{
+ a = 0;
+ a = ({}); /* { dg-error "not ignored" "void stmt expr" } */
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14765