On Thu, Oct 29 2015, Andreas Arnez wrote:
> On Thu, Oct 29 2015, Bernd Schmidt wrote:
>> [...]
>> 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 debug
On Thu, Oct 29 2015, Bernd Schmidt wrote:
> On 10/23/2015 11:14 AM, Andreas Arnez wrote:
>> + 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
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
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html
On Fri, Oct 23 2015, Andreas Arnez wrote:
> After parsing an unconditional "while"- or "for"-loop, the C front-end
> generates a backward-goto statement and implicitly sets its location to
> the current input_location. But in some
After parsing an unconditional "while"- or "for"-loop, the C front-end
generates a backward-goto statement and implicitly sets its location to
the current input_location. But in some cases the parser peeks ahead
first, such that input_location already points to the line after the
loop and the gene
