On Sat, Mar 21, 2020 at 09:40:24AM +0100, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Mar 19, 2020 at 09:38:30PM +0000, Joseph Myers wrote:
> > The second patch is OK.
>
> Unfortunately the patch broke
> +FAIL: gcc.dg/pr20245-1.c (internal compiler error)
> +FAIL: gcc.dg/pr20245-1.c (test for excess errors)
> +FAIL: gcc.dg/pr28419.c (internal compiler error)
> +FAIL: gcc.dg/pr28419.c (test for excess errors)
> on some targets (and under valgrind on the rest of them).
>
> Those functions don't have the opening { and so c_parser_compound_statement
> returned error_mark_node before initializing *endlocp.
> So, either we can initialize it in that case too:
> --- gcc/c/c-parser.c 2020-03-20 22:09:39.659411721 +0100
> +++ gcc/c/c-parser.c 2020-03-21 09:36:44.455705261 +0100
> @@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
> if we have just prepared to enter a function body. */
> stmt = c_begin_compound_stmt (true);
> c_end_compound_stmt (brace_loc, stmt, true);
> + if (endlocp)
> + *endlocp = brace_loc;
> return error_mark_node;
> }
> stmt = c_begin_compound_stmt (true);
> or perhaps simpler initialize it to the function_start_locus at the
> beginning and have those functions without { have function_start_locus ==
> function_end_locus like the __GIMPLE functions (where propagating the
> closing } seemed too difficult).
>
> The following patch has been successfully bootstrapped/regtested on
> x86_64-linux and i686-linux and tested on the testcases under valgrind,
> ok for trunk (or do you prefer the above hunk instead)?
>
> 2020-03-21 Jakub Jelinek <ja...@redhat.com>
>
> PR gcov-profile/94029
> PR c/94239
> * c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
> the function_start_locus location. Don't do that afterwards for the
> __GIMPLE body parsing.
I'm fine with this one, thanks.
Marek
