This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C PATCH] Fix ICE on invalid Cilk+ code (PR c/69798)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Fri, 4 Mar 2016 14:04:37 +0100
- Subject: Re: [C PATCH] Fix ICE on invalid Cilk+ code (PR c/69798)
- Authentication-results: sourceware.org; auth=none
- References: <20160303141541 dot GD10006 at redhat dot com> <56D92252 dot 1020007 at redhat dot com>
On Thu, Mar 03, 2016 at 10:51:14PM -0700, Jeff Law wrote:
> On 03/03/2016 07:15 AM, Marek Polacek wrote:
> >This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
> >_Cilk_spawn (void) is invalid. The function call after the cilk_spawn keyword
> >is parsed using recursive call in c_parser_postfix_expression (case
> >RID_CILK_SPAWN). Now, c_parser_postfix_expression sees '(' followed by a
> >typename, so it thinks we're inside a compound literal, which means it expects
> >'{', but that isn't there, so we crash on the assert in c_parser_braced_init:
> >gcc_assert (c_parser_next_token_is (parser, CPP_OPEN_BRACE));
> >But as the comment in c_parser_postfix_expression says, the code for parsing
> >a compound literal here is likely dead. I made an experiment and added
> >gcc_unreachable () in that block, ran regtest, and there were no failures.
> >Thus it should be safe to just remove the code, which also fixes this ICE; with
> >the patch we just give a proper error and don't crash anymore.
> >
> >Bootstrapped/regtested on x86_64-linux, ok for trunk? I'm actually slightly
> >nervous about the change, so maybe better table until gcc7?
> >
> >2016-03-03 Marek Polacek <polacek@redhat.com>
> >
> > PR c/69798
> > * c-parser.c (c_parser_postfix_expression): Remove code dealing with
> > compound literals.
> >
> > * gcc.dg/cilk-plus/pr69798-1.c: New test.
> > * gcc.dg/cilk-plus/pr69798-2.c: New test.
> FWIW, I don't particularly like this version. My worry about just removing
> this code is that I expect our testsuite doesn't cover parsing issues all
> that well.
>
> I'd feel better if it'd been run through one of the commercial suites. Even
> then those suites don't cover the GNU extensions, but at least the scope of
> things that might go wrong is significantly diminished.
I agree but unfortunately I don't have the means to run such a suite. Compound
literals are ISO C99 thing, so hopefully they are well-covered in those test
suites.
Ultimately I want to either do away with the code, or add tests that exercise
the codepath.
Marek