This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Don't ICE if COMPOUND_LITERAL_EXPR's DECL_INITIAL isn't CONSTRUCTOR (PR c/54363)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Sep 2012 13:06:07 +0200
- Subject: Re: [PATCH] Don't ICE if COMPOUND_LITERAL_EXPR's DECL_INITIAL isn't CONSTRUCTOR (PR c/54363)
- References: <20120824212253.GI1999@tucnak.redhat.com> <Pine.LNX.4.64.1208242138530.28999@digraph.polyomino.org.uk>
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