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:
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
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.
>
>
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
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
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
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 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
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' back-jum
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
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
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
&g
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 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
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
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
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 bootstrappedregrtested it on
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 know
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 for GCC
host compiler (= 3.4) will use
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 sub-qualified type in a separate
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 ~sub_qual) != NULL_TREE)
+return true
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
23 matches
Mail list logo
