diff mbox

Don't ICE if COMPOUND_LITERAL_EXPR's DECL_INITIAL isn't CONSTRUCTOR (PR c/54363)

Message ID 20120824212253.GI1999@tucnak.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek Aug. 24, 2012, 9:22 p.m. UTC 
Hi!

On this testcase, we ICE in optimize_compound_literals_in_ctor
because init isn't CONSTRUCTOR, but the recursive call relies on it
being a CONSTRUCTOR.

Either we can add that check as the patch does, making the optimization
tiny bit more robust (the rest of the gimplifier handles non-CONSTRUCTOR
DECL_INITIAL of COMPOUND_LITERAL_EXPR just fine), or the C FE would need to
be somehow fixed to always emit a CONSTRUCTOR.

Joseph, what do you prefer here?

Bootstrapped/regtested on x86_64-linux and i686-linux.

2012-08-24  Jakub Jelinek  <jakub@redhat.com>

	PR c/54363
	* gimplify.c (optimize_compound_literals_in_ctor): Only recurse
	if init is a CONSTRUCTOR.

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


	Jakub

Comments

Joseph Myers Aug. 24, 2012, 9:39 p.m. UTC | #1 
On Fri, 24 Aug 2012, Jakub Jelinek wrote:

> Hi!
> 
> On this testcase, we ICE in optimize_compound_literals_in_ctor
> because init isn't CONSTRUCTOR, but the recursive call relies on it
> being a CONSTRUCTOR.
> 
> Either we can add that check as the patch does, making the optimization
> tiny bit more robust (the rest of the gimplifier handles non-CONSTRUCTOR
> DECL_INITIAL of COMPOUND_LITERAL_EXPR just fine), or the C FE would need to
> be somehow fixed to always emit a CONSTRUCTOR.
> 
> Joseph, what do you prefer here?

I prefer the gimplifier approach here (allowing COMPOUND_LITERAL_EXPRs to 
use anything that would be a valid initializer for the relevant type).
Richard Biener Sept. 3, 2012, 11:06 a.m. UTC | #2 
On Fri, Aug 24, 2012 at 11:39 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 24 Aug 2012, Jakub Jelinek wrote:
>
>> Hi!
>>
>> On this testcase, we ICE in optimize_compound_literals_in_ctor
>> because init isn't CONSTRUCTOR, but the recursive call relies on it
>> being a CONSTRUCTOR.
>>
>> Either we can add that check as the patch does, making the optimization
>> tiny bit more robust (the rest of the gimplifier handles non-CONSTRUCTOR
>> DECL_INITIAL of COMPOUND_LITERAL_EXPR just fine), or the C FE would need to
>> be somehow fixed to always emit a CONSTRUCTOR.
>>
>> Joseph, what do you prefer here?
>
> I prefer the gimplifier approach here (allowing COMPOUND_LITERAL_EXPRs to
> use anything that would be a valid initializer for the relevant type).

The patch is ok.

Thanks,
Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com
diff mbox

Patch

--- gcc/gimplify.c.jj	2012-08-15 10:55:33.000000000 +0200
+++ gcc/gimplify.c	2012-08-24 11:01:55.253815273 +0200
@@ -3857,7 +3857,8 @@  optimize_compound_literals_in_ctor (tree
 
 	  if (!TREE_ADDRESSABLE (value)
 	      && !TREE_ADDRESSABLE (decl)
-	      && init)
+	      && init
+	      && TREE_CODE (init) == CONSTRUCTOR)
 	    newval = optimize_compound_literals_in_ctor (init);
 	}
       if (newval == value)
--- gcc/testsuite/gcc.dg/pr54363.c.jj	2012-08-24 11:34:49.857494287 +0200
+++ gcc/testsuite/gcc.dg/pr54363.c	2012-08-24 11:36:20.943061045 +0200
@@ -0,0 +1,12 @@ 
+/* PR c/54363 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99" } */
+
+struct S { char **a; };
+
+void
+test (void)
+{
+  struct S b = { .a = (char **) { "a", "b" } }; /* { dg-warning "(initialization|excess elements)" } */
+  struct S c = { .a = (char *[]) { "a", "b" } };
+}