| Message ID | 20200321084024.GA2156@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | c: Fix up cfun->function_end_locus on invalid function bodies [PR94239] | expand |
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
--- 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. --- gcc/c/c-parser.c.jj 2020-03-19 22:55:49.694691865 +0100 +++ gcc/c/c-parser.c 2020-03-20 22:09:39.659411721 +0100 @@ -2469,9 +2469,10 @@ c_parser_declaration_or_fndef (c_parser omp_declare_simd_clauses); if (oacc_routine_data) c_finish_oacc_routine (oacc_routine_data, current_function_decl, true); + location_t startloc = c_parser_peek_token (parser)->location; DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus - = c_parser_peek_token (parser)->location; - location_t endloc; + = startloc; + location_t endloc = startloc; /* If the definition was marked with __RTL, use the RTL parser now, consuming the function body. */ @@ -2499,8 +2500,6 @@ c_parser_declaration_or_fndef (c_parser specs->declspec_il, specs->entry_bb_count); in_late_binary_op = saved; - struct function *fun = DECL_STRUCT_FUNCTION (current_function_decl); - endloc = fun->function_start_locus; } else fnbody = c_parser_compound_statement (parser, &endloc);
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: Jakub