This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/14765] [3.3/3.4/3.5 Regression] [tree-ssa] ice-on-invalid-code, ICE while compiling ({}) expression


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]