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.