On 10/23/2015 11:14 AM, Andreas Arnez wrote:
This patch adds a new parameter to c_finish_loop that expclitly
specifies the location to be used for the loop iteration. All calls to
c_finish_loop are adjusted accordingly.
I think the general principle of this is probably ok.
+ bool is_braced = c_parser_next_token_is (parser, CPP_OPEN_BRACE);
body = c_parser_c99_block_statement (parser);
+ location_t iter_loc = is_braced ? input_location : loc;
token_indent_info next_tinfo
= get_token_indent_info (c_parser_peek_token (parser));
warn_for_misleading_indentation (while_tinfo, body_tinfo, next_tinfo);
- c_finish_loop (loc, cond, NULL, body, c_break_label, c_cont_label, true);
+ c_finish_loop (loc, iter_loc, cond, NULL, body, c_break_label,
+ c_cont_label, true);
I'm not entirely sure I understand what the is_braced logic is trying to
achieve. I tried the patch out with the debugger on the testcase you
provided, and I get slightly strange behaviour in f2:
Starting program: /local/src/egcs/bwork-git/gcc/a.out
Breakpoint 7, f2 () at pr67192.c:32
32 if (last ())
(gdb) cont
Continuing.
Breakpoint 6, f2 () at pr67192.c:31
31 while (1)
(gdb)
i.e. the breakpoint on the code inside the loop is reached before the
while statement itself. This may be the expected behaviour with your
patch, but I'm not sure it's really desirable for debugging.
In f4 placing a breakpoint on the while (1) just places it on the if
(last ()) line. The same behaviour appears to occur for both while loops
with the system gcc-4.8.5. So I think there are some strange
inconsistencies going on here, and for debugging the old behaviour may
well be better.
I'd suggest you commit your original patch to fix the misleading-indent
problem while we sort this out.
Bernd
