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