[C PATCH] Fix ICE on invalid Cilk+ code (PR c/69798)

Jeff Law law@redhat.com
Fri Mar 4 05:51:00 GMT 2016


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.


Jeff




More information about the Gcc-patches mailing list