[PATCH] c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]

[Marek Polacek]

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  <jakub@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