Since r223098 ("Implement -Wmisleading-indentation") the backward-jump
generated for a C while- or for-loop can get the wrong line number.
This is because the check for misleading indentation peeks ahead one
token, advancing input_location to after the loop, and then
c_finish_loop() creates the bac
On Tue, Oct 13 2015, Bernd Schmidt wrote:
> One could argue that peek_token should not have an effect on
> input_location, and in fact cpp_peek_token seems to take steps that
> this does not happen, but it looks like c_parser_peek_token does not
> use that mechanism.
Yes, the C/C++ parsers differ
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
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 cu
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 ?
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 no
it removes the dependency on input_location for this purpose.
Tested on s390x without regressions.
Previous versions:
* v1: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html
* v2: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html
Andreas Arnez (2):
[PR debug/67192] Fix C loops'
Since r223098 ("Implement -Wmisleading-indentation") the backward-jump
generated for a C while- or for-loop can get the wrong line number.
This is because the check for misleading indentation peeks ahead one
token, advancing input_location to after the loop, and then
c_finish_loop() creates the bac
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
On Thu, Nov 05 2015, Bernd Schmidt wrote:
> On 11/04/2015 05:17 PM, Andreas Arnez wrote:
>>
>> gcc/c/ChangeLog:
>>
>> PR debug/67192
>> * c-parser.c (c_parser_while_statement): Finish the loop before
>> parsing ahead for misleading inden
On Thu, Nov 05 2015, Bernd Schmidt wrote:
> On 11/05/2015 12:33 PM, Andreas Arnez wrote:
>
>> Thanks again for reviewing. Are you going to look at patch #2 as well?
>
> Yeah, still thinking about that one.
>
>>> Does C++ have similar issues?
>>
>> Not th
On Sat, Nov 07 2015, Jeff Law wrote:
> Also OK. And please consider using those tests with the C++ compiler
> to see if it's suffering from the same problem.
Not really, but there's still an issue.
In the C front-end the back-jump's location of an unconditional loop was
sometimes set to the tok
While fixing PR67192 it turned out that there are multiple potential
issues with the location of the backward-jump statement generated by the
C and C++ front-ends for an unconditional loop.
First, due to a bug the C front-end had sometimes set the location to
the token following the loop. This is
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
> gcc/cp/ChangeLog:
>
> * cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location
> to start of loop body instead of start of loop.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/guality/pr67192.C: New tes
Ping?
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
I guess we want C and C++ behave the same here?
> gcc/cp/ChangeLog:
>
> * cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location
> to start of loop body instead of start of loop.
>
> gcc/testsuite/ChangeLog:
SVN commit r230979 always associates a loop's back-jump with the start
of the loop body. This caused a regression for gcov with conditional
loops, because then the loop body appears to be covered twice per
iteration.
gcc/cp/ChangeLog:
PR gcov-profile/68603
* cp-gimplify.c (generi
On Wed, Dec 02 2015, Alan Lawrence wrote:
[...]
> Since this, we've been seeing these tests fail natively on AArch64 and ARM:
>
> FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 gcov: 3 failures in line
> counts, 0 in branch percentages, 0 in return percentages, 0 in
> intermediate format
> FAIL: g++.d
On Tue, May 12 2015, David Malcolm wrote:
> On Tue, 2015-05-12 at 17:21 -0400, David Malcolm wrote:
> [...]
>> Thanks; I've removed the new warning from -Wall, making the appropriate
>> trivial doc changes, and committed it to trunk (r223098; attached).
>
> ...having bootstrapped®rtested it on x86
On Sat, Sep 20 2014, Mark Wielaard wrote:
> When adding DW_TAG_restrict_type I made a mistake when updating the
> code that handled types with multiple modifiers. This patch fixes it
> by putting the logic for finding the "sub-qualified" type in a separate
> function and fall back to adding the mo
On Mon, Sep 22 2014, Andreas Arnez wrote:
> On Sat, Sep 20 2014, Mark Wielaard wrote:
>
>> When adding DW_TAG_restrict_type I made a mistake when updating the
>> code that handled types with multiple modifiers. This patch fixes it
>> by putting the logic for finding the &
On Tue, Sep 23 2014, Mark Wielaard wrote:
> On Mon, Sep 22, 2014 at 10:59:38AM +0200, Andreas Arnez wrote:
>> > + sub_qual = TYPE_QUAL_RESTRICT;
>> > + if ((sub_quals & ~sub_qual) != TYPE_UNQUALIFIED
>> > + && get_qualified_type (type, sub_quals &
On Tue, Sep 23 2014, Mark Wielaard wrote:
> This certainly looks nicer than how I wrote it. It took me a while
> (again) to realize why this works. We rely on the fact that earlier in
> the function a match would have been found if there was already a fully
> qualified type available. So here we k
On Wed, Sep 24 2014, Jakub Jelinek wrote:
> On Wed, Sep 24, 2014 at 02:40:14PM +0200, Andreas Arnez wrote:
>> A few style aspects I'm not sure about:
>>
>> * Is it OK to use __builtin_popcount in tree.c?
>
> Definitely not, you can use popcount_hwi instead, which
23 matches
Mail list logo
