diff mbox series

c: Fix ICE with cast to VLA [93576]

Message ID 20200213175708.GJ17695@tucnak
State New
Headers show
Series c: Fix ICE with cast to VLA [93576] | expand

Commit Message

Jakub Jelinek Feb. 13, 2020, 5:57 p.m. UTC 
Hi!

The following testcase ICEs, because the PR84305 changes try to evaluate
the size earlier.  If size has side-effects, that is desirable, and the
side-effects will actually be wrapped in a SAVE_EXPR.  The problem on this
testcase is that there are no side-effects, and c_fully_fold doesn't fold
those COMPOUND_EXPRs to constant, and while before gimplification we unshare
trees found in the expressions, the unsharing doesn't involve TYPE_SIZE etc.
of used types.  Gimplification is destructive though, so when we gimplify
the two nested COMPOUND_EXPRs and then try to gimplify it the second time
for the TYPE_SIZEs, we ICE.
Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and
their operands in there aren't unshared, but I really don't see a point of
evaluating expressions that don't have side-effects before, so instead
this just pushes there expressions that do have side-effects.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches?

2020-02-13  Jakub Jelinek  <jakub@redhat.com>

	PR c/93576
	* c-decl.c (grokdeclarator): If this_size_varies, only push size into
	*expr if it has side effects.

	* gcc.dg/pr93576.c: New test.


	Jakub

Comments

Jeff Law Feb. 13, 2020, 7:35 p.m. UTC | #1 
On Thu, 2020-02-13 at 18:57 +0100, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs, because the PR84305 changes try to evaluate
> the size earlier.  If size has side-effects, that is desirable, and the
> side-effects will actually be wrapped in a SAVE_EXPR.  The problem on this
> testcase is that there are no side-effects, and c_fully_fold doesn't fold
> those COMPOUND_EXPRs to constant, and while before gimplification we unshare
> trees found in the expressions, the unsharing doesn't involve TYPE_SIZE etc.
> of used types.  Gimplification is destructive though, so when we gimplify
> the two nested COMPOUND_EXPRs and then try to gimplify it the second time
> for the TYPE_SIZEs, we ICE.
> Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and
> their operands in there aren't unshared, but I really don't see a point of
> evaluating expressions that don't have side-effects before, so instead
> this just pushes there expressions that do have side-effects.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> release branches?
> 
> 2020-02-13  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c/93576
> 	* c-decl.c (grokdeclarator): If this_size_varies, only push size into
> 	*expr if it has side effects.
> 
> 	* gcc.dg/pr93576.c: New test.
OK
jeff
>
diff mbox series

Patch

--- gcc/c/c-decl.c.jj	2020-01-15 12:34:15.079253187 +0100
+++ gcc/c/c-decl.c	2020-02-13 13:49:06.427304070 +0100
@@ -6512,11 +6512,14 @@  grokdeclarator (const struct c_declarato
 		  }
 		if (this_size_varies)
 		  {
-		    if (*expr)
-		      *expr = build2 (COMPOUND_EXPR, TREE_TYPE (size),
-				      *expr, size);
-		    else
-		      *expr = size;
+		    if (TREE_SIDE_EFFECTS (size))
+		      {
+			if (*expr)
+			  *expr = build2 (COMPOUND_EXPR, TREE_TYPE (size),
+					  *expr, size);
+			else
+			  *expr = size;
+		      }
 		    *expr_const_operands &= size_maybe_const;
 		  }
 	      }
--- gcc/testsuite/gcc.dg/pr93576.c.jj	2020-02-13 13:53:06.089708612 +0100
+++ gcc/testsuite/gcc.dg/pr93576.c	2020-02-13 13:52:40.041099237 +0100
@@ -0,0 +1,10 @@ 
+/* PR c/93576 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo (void)
+{
+  int b[] = { 0 };
+  (char (*)[(1, 7, 2)]) 0;
+}