Fix c/69522, memory management issue in c-parser

[Jeff Law]

On 01/29/2016 04:40 AM, Bernd Schmidt wrote:
> Let's say we have
>
> struct a {
>   int x[1];
>   int y[1];
> } x = { 0, { 0 } };
>             ^
>
> When we reach the marked brace, we call into push_init_level, where we
> notice that we have implicit initializers (for x[]) lying around that we
> should deal with now that we've seen another open brace. The problem is
> that we've created a new obstack for the initializer of y, and this is
> where we also put data for the inits of x, freeing it when we see the
> close brace for the initialization of y.
>
> In the actual testcase, which is a little more complex to actually
> demonstrate the issue, we end up allocating two init elts at the same
> address (because of premature freeing) and place them in the same tree,
> which ends up containing a cycle because of this. Then we hang.
>
> Fixed by this patch, which splits off a new function
> finish_implicit_inits from push_init_level and ensures it's called with
> the outer obstack instead of the new one in the problematic case.
>
> Bootstrapped and tested on x86_64-linux, ok?
>
>
> Bernd
>
> braced-init.diff
>
>
> c/
> 	PR c/69522
> 	* c-parser.c (c_parser_braced_init): New arg outer_obstack.  All
> 	callers changed.  If nested_p is true, use it to call
> 	finish_implicit_inits.
> 	* c-tree.h (finish_implicit_inits): Declare.
> 	* c-typeck.c (finish_implicit_inits): New function.  Move code
> 	from ...
> 	(push_init_level): ... here.
> 	(set_designator, process_init_element): Call finish_implicit_inits.
>
> testsuite/
> 	PR c/69522
> 	gcc.dg/pr69522.c: New test.
OK.  Thanks for tracking this down.

Thanks,
Jeff