* [PATCH v3 0/2] Fix C loops' back-jump location @ 2015-11-04 16:15 Andreas Arnez 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez 2015-11-04 16:18 ` [PATCH v3 2/2] [PR debug/67192] Further fix " Andreas Arnez 0 siblings, 2 replies; 12+ messages in thread From: Andreas Arnez @ 2015-11-04 16:15 UTC (permalink / raw) To: gcc-patches Another iteration of trying to fix the regression caused by r223098 ("Implement -Wmisleading-indentation"). Patch #1 is the same as v1, except for some minor changes to the test case. Patch #2 fixes some additional cases where the back-jump's location was set wrongly, and 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-jump location [PR debug/67192] Further fix C loops' back-jump location gcc/c/c-parser.c | 13 +++--- gcc/c/c-typeck.c | 10 +++++ gcc/testsuite/gcc.dg/guality/pr67192.c | 79 ++++++++++++++++++++++++++++++++++ 3 files changed, 96 insertions(+), 6 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/guality/pr67192.c -- 2.3.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-04 16:15 [PATCH v3 0/2] Fix C loops' back-jump location Andreas Arnez @ 2015-11-04 16:18 ` Andreas Arnez 2015-11-05 9:21 ` Bernd Schmidt ` (2 more replies) 2015-11-04 16:18 ` [PATCH v3 2/2] [PR debug/67192] Further fix " Andreas Arnez 1 sibling, 3 replies; 12+ messages in thread From: Andreas Arnez @ 2015-11-04 16:18 UTC (permalink / raw) To: gcc-patches 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 back-jump and calls add_stmt(), which assigns input_location to the statement by default. This patch swaps the check for misleading indentation with the finishing of the loop, such that input_location still has the right value at the time of any invocations of add_stmt(). Note that this does not fully cover all cases where the back-jump gets the wrong location. gcc/c/ChangeLog: PR debug/67192 * c-parser.c (c_parser_while_statement): Finish the loop before parsing ahead for misleading indentation. (c_parser_for_statement): Likewise. gcc/testsuite/ChangeLog: PR debug/67192 * gcc.dg/guality/pr67192.c: New test. --- gcc/c/c-parser.c | 13 +++++---- gcc/testsuite/gcc.dg/guality/pr67192.c | 53 ++++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+), 6 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/guality/pr67192.c diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index ec88c65..0c5e4e9 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -5435,13 +5435,13 @@ c_parser_while_statement (c_parser *parser, bool ivdep) = get_token_indent_info (c_parser_peek_token (parser)); body = c_parser_c99_block_statement (parser); + c_finish_loop (loc, cond, NULL, body, c_break_label, c_cont_label, true); + add_stmt (c_end_compound_stmt (loc, block, flag_isoc99)); 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); - add_stmt (c_end_compound_stmt (loc, block, flag_isoc99)); c_break_label = save_break; c_cont_label = save_cont; } @@ -5725,15 +5725,16 @@ c_parser_for_statement (c_parser *parser, bool ivdep) body = c_parser_c99_block_statement (parser); - token_indent_info next_tinfo - = get_token_indent_info (c_parser_peek_token (parser)); - warn_for_misleading_indentation (for_tinfo, body_tinfo, next_tinfo); - if (is_foreach_statement) objc_finish_foreach_loop (loc, object_expression, collection_expression, body, c_break_label, c_cont_label); else c_finish_loop (loc, cond, incr, body, c_break_label, c_cont_label, true); add_stmt (c_end_compound_stmt (loc, block, flag_isoc99 || c_dialect_objc ())); + + token_indent_info next_tinfo + = get_token_indent_info (c_parser_peek_token (parser)); + warn_for_misleading_indentation (for_tinfo, body_tinfo, next_tinfo); + c_break_label = save_break; c_cont_label = save_cont; } diff --git a/gcc/testsuite/gcc.dg/guality/pr67192.c b/gcc/testsuite/gcc.dg/guality/pr67192.c new file mode 100644 index 0000000..f6382ef --- /dev/null +++ b/gcc/testsuite/gcc.dg/guality/pr67192.c @@ -0,0 +1,53 @@ +/* PR debug/67192 */ +/* { dg-do run } */ +/* { dg-options "-g -Wmisleading-indentation" } */ + +volatile int cnt = 0; + +__attribute__((noinline, noclone)) static int +last (void) +{ + return ++cnt % 5 == 0; +} + +__attribute__((noinline, noclone)) static void +do_it (void) +{ + asm volatile ("" : : "r" (&cnt) : "memory"); +} + +__attribute__((noinline, noclone)) static void +f1 (void) +{ + for (;; do_it()) + { + if (last ()) + break; + } + do_it (); /* { dg-final { gdb-test 27 "cnt" "5" } } */ +} + +__attribute__((noinline, noclone)) static void +f2 (void) +{ + while (1) + { + if (last ()) + break; + do_it (); + } + do_it (); /* { dg-final { gdb-test 39 "cnt" "10" } } */ +} + +void (*volatile fnp1) (void) = f1; +void (*volatile fnp2) (void) = f2; + +int +main () +{ + asm volatile ("" : : "r" (&fnp1) : "memory"); + asm volatile ("" : : "r" (&fnp2) : "memory"); + fnp1 (); + fnp2 (); + return 0; +} -- 2.3.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez @ 2015-11-05 9:21 ` Bernd Schmidt 2015-11-05 11:33 ` Andreas Arnez 2015-11-07 5:13 ` Jeff Law 2015-11-09 15:36 ` Andreas Krebbel 2 siblings, 1 reply; 12+ messages in thread From: Bernd Schmidt @ 2015-11-05 9:21 UTC (permalink / raw) To: Andreas Arnez, gcc-patches 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 indentation. > (c_parser_for_statement): Likewise. This is OK. Does C++ have similar issues? Bernd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-05 9:21 ` Bernd Schmidt @ 2015-11-05 11:33 ` Andreas Arnez 2015-11-05 11:58 ` Bernd Schmidt 0 siblings, 1 reply; 12+ messages in thread From: Andreas Arnez @ 2015-11-05 11:33 UTC (permalink / raw) To: Bernd Schmidt; +Cc: gcc-patches 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 indentation. >> (c_parser_for_statement): Likewise. > > This is OK. Thanks again for reviewing. Are you going to look at patch #2 as well? > Does C++ have similar issues? Not this particular issue, AFAIK. But I've just looked at how C++ fares with the enhanced version of pr67192.c from patch #2. There I see the following: Breakpoint 2, f4 () at pr67192.cc:54 (gdb) p cnt $1 = 16 I.e., when breaking on "while (1)" the first loop iteration has already executed. This is because the C++ parser assigns the backward-goto to the 'while' token. It's the same issue you pointed at with version 2 of my patch. Shall I open a bug for that? -- Andreas ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-05 11:33 ` Andreas Arnez @ 2015-11-05 11:58 ` Bernd Schmidt 2015-11-05 15:30 ` Andreas Arnez 0 siblings, 1 reply; 12+ messages in thread From: Bernd Schmidt @ 2015-11-05 11:58 UTC (permalink / raw) To: Andreas Arnez; +Cc: gcc-patches 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 this particular issue, AFAIK. But I've just looked at how C++ fares > with the enhanced version of pr67192.c from patch #2. There I see the > following: > > Breakpoint 2, f4 () at pr67192.cc:54 > (gdb) p cnt > $1 = 16 > > I.e., when breaking on "while (1)" the first loop iteration has already > executed. This is because the C++ parser assigns the backward-goto to > the 'while' token. It's the same issue you pointed at with version 2 of > my patch. > > Shall I open a bug for that? I'd obviously prefer if you'd manage to get the two frontends behave identically. The alternative would be to open a bug. Bernd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-05 11:58 ` Bernd Schmidt @ 2015-11-05 15:30 ` Andreas Arnez 0 siblings, 0 replies; 12+ messages in thread From: Andreas Arnez @ 2015-11-05 15:30 UTC (permalink / raw) To: Bernd Schmidt; +Cc: gcc-patches 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 this particular issue, AFAIK. But I've just looked at how C++ fares >> with the enhanced version of pr67192.c from patch #2. There I see the >> following: >> >> Breakpoint 2, f4 () at pr67192.cc:54 >> (gdb) p cnt >> $1 = 16 >> >> I.e., when breaking on "while (1)" the first loop iteration has already >> executed. This is because the C++ parser assigns the backward-goto to >> the 'while' token. It's the same issue you pointed at with version 2 of >> my patch. >> >> Shall I open a bug for that? > > I'd obviously prefer if you'd manage to get the two frontends behave > identically. The alternative would be to open a bug. OK, I guess it depends on whether we want to go the route of patch #2. If so, it seems we can do the same for the C++ parser, like in the patch below. Note that I've not tested this very much. -- >8 -- Subject: [PATCH] C++: Fix location of loop statement --- gcc/cp/cp-gimplify.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c index e4b50e5..d9bb708 100644 --- a/gcc/cp/cp-gimplify.c +++ b/gcc/cp/cp-gimplify.c @@ -266,7 +266,12 @@ genericize_cp_loop (tree *stmt_p, location_t start_locus, tree cond, tree body, loop = stmt_list; } else - loop = build1_loc (start_locus, LOOP_EXPR, void_type_node, stmt_list); + { + location_t loc = EXPR_LOCATION (expr_first (body)); + if (loc == UNKNOWN_LOCATION) + loc = start_locus; + loop = build1_loc (loc, LOOP_EXPR, void_type_node, stmt_list); + } stmt_list = NULL; append_to_statement_list (loop, &stmt_list); -- 2.3.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez 2015-11-05 9:21 ` Bernd Schmidt @ 2015-11-07 5:13 ` Jeff Law 2015-11-09 15:36 ` Andreas Krebbel 2 siblings, 0 replies; 12+ messages in thread From: Jeff Law @ 2015-11-07 5:13 UTC (permalink / raw) To: Andreas Arnez, gcc-patches On 11/04/2015 09:17 AM, Andreas Arnez wrote: > 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 back-jump and calls add_stmt(), which > assigns input_location to the statement by default. > > This patch swaps the check for misleading indentation with the finishing > of the loop, such that input_location still has the right value at the > time of any invocations of add_stmt(). Note that this does not fully > cover all cases where the back-jump gets the wrong location. > > gcc/c/ChangeLog: > > PR debug/67192 > * c-parser.c (c_parser_while_statement): Finish the loop before > parsing ahead for misleading indentation. > (c_parser_for_statement): Likewise. > > gcc/testsuite/ChangeLog: > > PR debug/67192 > * gcc.dg/guality/pr67192.c: New test. OK. You might consider testing C++ on the same tests. I wouldn't be surprised if it shows the same problem. jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez 2015-11-05 9:21 ` Bernd Schmidt 2015-11-07 5:13 ` Jeff Law @ 2015-11-09 15:36 ` Andreas Krebbel 2 siblings, 0 replies; 12+ messages in thread From: Andreas Krebbel @ 2015-11-09 15:36 UTC (permalink / raw) To: Andreas Arnez; +Cc: gcc-patches On 11/04/2015 05:17 PM, Andreas Arnez wrote: > 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 back-jump and calls add_stmt(), which > assigns input_location to the statement by default. > > This patch swaps the check for misleading indentation with the finishing > of the loop, such that input_location still has the right value at the > time of any invocations of add_stmt(). Note that this does not fully > cover all cases where the back-jump gets the wrong location. > > gcc/c/ChangeLog: > > PR debug/67192 > * c-parser.c (c_parser_while_statement): Finish the loop before > parsing ahead for misleading indentation. > (c_parser_for_statement): Likewise. > > gcc/testsuite/ChangeLog: > > PR debug/67192 > * gcc.dg/guality/pr67192.c: New test. Applied. Thanks! -Andreas- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 2/2] [PR debug/67192] Further fix C loops' back-jump location 2015-11-04 16:15 [PATCH v3 0/2] Fix C loops' back-jump location Andreas Arnez 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez @ 2015-11-04 16:18 ` Andreas Arnez 2015-11-07 5:15 ` Jeff Law 2015-11-09 15:36 ` Andreas Krebbel 1 sibling, 2 replies; 12+ messages in thread From: Andreas Arnez @ 2015-11-04 16:18 UTC (permalink / raw) To: gcc-patches 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 generated backward-goto gets the wrong line number. One way this can occur is with a loop body consisting of an "if" statement, because then the parser peeks for an optional "else" before finishing the loop. Another way occurred after r223098 ("Implement -Wmisleading-indentation"), even with a loop body enclosed in braces. This was because the check for misleading indentation always peeks ahead one token as well. This patch avoids the use of input_location and sets the location of the backward-goto to the start of the loop body instead, or, if there is no loop body, to the start of the loop. gcc/c/ChangeLog: PR debug/67192 * c-typeck.c (c_finish_loop): For unconditional loops, set the location of the backward-goto to the start of the loop body. gcc/testsuite/ChangeLog: PR debug/67192 * gcc.dg/guality/pr67192.c (f3, f4): New functions. (main): Invoke them. --- gcc/c/c-typeck.c | 10 ++++++++++ gcc/testsuite/gcc.dg/guality/pr67192.c | 26 ++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c index 2363b9b..e4c3720 100644 --- a/gcc/c/c-typeck.c +++ b/gcc/c/c-typeck.c @@ -9878,6 +9878,16 @@ c_finish_loop (location_t start_locus, tree cond, tree incr, tree body, exit = fold_build3_loc (input_location, COND_EXPR, void_type_node, cond, exit, t); } + else + { + /* For the backward-goto's location of an unconditional loop + use the beginning of the body, or, if there is none, the + top of the loop. */ + location_t loc = EXPR_LOCATION (expr_first (body)); + if (loc == UNKNOWN_LOCATION) + loc = start_locus; + SET_EXPR_LOCATION (exit, loc); + } add_stmt (top); } diff --git a/gcc/testsuite/gcc.dg/guality/pr67192.c b/gcc/testsuite/gcc.dg/guality/pr67192.c index f6382ef..946e68f 100644 --- a/gcc/testsuite/gcc.dg/guality/pr67192.c +++ b/gcc/testsuite/gcc.dg/guality/pr67192.c @@ -39,15 +39,41 @@ f2 (void) do_it (); /* { dg-final { gdb-test 39 "cnt" "10" } } */ } +__attribute__((noinline, noclone)) static void +f3 (void) +{ + for (;; do_it()) + if (last ()) + break; + do_it (); /* { dg-final { gdb-test 48 "cnt" "15" } } */ +} + +__attribute__((noinline, noclone)) static void +f4 (void) +{ + while (1) /* { dg-final { gdb-test 54 "cnt" "15" } } */ + if (last ()) + break; + else + do_it (); + do_it (); /* { dg-final { gdb-test 59 "cnt" "20" } } */ +} + void (*volatile fnp1) (void) = f1; void (*volatile fnp2) (void) = f2; +void (*volatile fnp3) (void) = f3; +void (*volatile fnp4) (void) = f4; int main () { asm volatile ("" : : "r" (&fnp1) : "memory"); asm volatile ("" : : "r" (&fnp2) : "memory"); + asm volatile ("" : : "r" (&fnp3) : "memory"); + asm volatile ("" : : "r" (&fnp4) : "memory"); fnp1 (); fnp2 (); + fnp3 (); + fnp4 (); return 0; } -- 2.3.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 2/2] [PR debug/67192] Further fix C loops' back-jump location 2015-11-04 16:18 ` [PATCH v3 2/2] [PR debug/67192] Further fix " Andreas Arnez @ 2015-11-07 5:15 ` Jeff Law 2015-11-09 17:59 ` Andreas Arnez 2015-11-09 15:36 ` Andreas Krebbel 1 sibling, 1 reply; 12+ messages in thread From: Jeff Law @ 2015-11-07 5:15 UTC (permalink / raw) To: Andreas Arnez, gcc-patches On 11/04/2015 09:18 AM, 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 cases the parser peeks ahead > first, such that input_location already points to the line after the > loop and the generated backward-goto gets the wrong line number. > > One way this can occur is with a loop body consisting of an "if" > statement, because then the parser peeks for an optional "else" before > finishing the loop. > > Another way occurred after r223098 ("Implement > -Wmisleading-indentation"), even with a loop body enclosed in braces. > This was because the check for misleading indentation always peeks ahead > one token as well. > > This patch avoids the use of input_location and sets the location of the > backward-goto to the start of the loop body instead, or, if there is no > loop body, to the start of the loop. > > gcc/c/ChangeLog: > > PR debug/67192 > * c-typeck.c (c_finish_loop): For unconditional loops, set the > location of the backward-goto to the start of the loop body. > > gcc/testsuite/ChangeLog: > > PR debug/67192 > * gcc.dg/guality/pr67192.c (f3, f4): New functions. > (main): Invoke them. Also OK. And please consider using those tests with the C++ compiler to see if it's suffering from the same problem. Thanks again! jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 2/2] [PR debug/67192] Further fix C loops' back-jump location 2015-11-07 5:15 ` Jeff Law @ 2015-11-09 17:59 ` Andreas Arnez 0 siblings, 0 replies; 12+ messages in thread From: Andreas Arnez @ 2015-11-09 17:59 UTC (permalink / raw) To: Jeff Law; +Cc: gcc-patches 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 token after the loop, particularly after the misleading-indent patch. This does *not* apply to C++. Before the misleading-indent patch the location was usually set to the last line of the loop instead. This may be slightly confusing when the loop body consists of an if-else statement: Breaking on that line then causes a breakpoint hit on every iteration even if the else-path is never executed. This issue does *not* apply to C++ either. But the C++ front-end always sets the location to the "while" or "for" token. This can cause confusion when setting a breakpoint there: When hitting it for the first time, one loop iteration will already have executed. For that issue I included an informal patch in my earlier post. It mimics the C patch and seems to fix the issue: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00478.html I'll go ahead and prepare a full patch (with test case, ChangeLog, etc.) for this. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 2/2] [PR debug/67192] Further fix C loops' back-jump location 2015-11-04 16:18 ` [PATCH v3 2/2] [PR debug/67192] Further fix " Andreas Arnez 2015-11-07 5:15 ` Jeff Law @ 2015-11-09 15:36 ` Andreas Krebbel 1 sibling, 0 replies; 12+ messages in thread From: Andreas Krebbel @ 2015-11-09 15:36 UTC (permalink / raw) To: Andreas Arnez; +Cc: gcc-patches On 11/04/2015 05:18 PM, 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 cases the parser peeks ahead > first, such that input_location already points to the line after the > loop and the generated backward-goto gets the wrong line number. > > One way this can occur is with a loop body consisting of an "if" > statement, because then the parser peeks for an optional "else" before > finishing the loop. > > Another way occurred after r223098 ("Implement > -Wmisleading-indentation"), even with a loop body enclosed in braces. > This was because the check for misleading indentation always peeks ahead > one token as well. > > This patch avoids the use of input_location and sets the location of the > backward-goto to the start of the loop body instead, or, if there is no > loop body, to the start of the loop. > > gcc/c/ChangeLog: > > PR debug/67192 > * c-typeck.c (c_finish_loop): For unconditional loops, set the > location of the backward-goto to the start of the loop body. > > gcc/testsuite/ChangeLog: > > PR debug/67192 > * gcc.dg/guality/pr67192.c (f3, f4): New functions. > (main): Invoke them. Applied. Thanks! -Andreas- ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-11-09 17:59 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-04 16:15 [PATCH v3 0/2] Fix C loops' back-jump location Andreas Arnez 2015-11-04 16:18 ` [PATCH v3 1/2] [PR debug/67192] " Andreas Arnez 2015-11-05 9:21 ` Bernd Schmidt 2015-11-05 11:33 ` Andreas Arnez 2015-11-05 11:58 ` Bernd Schmidt 2015-11-05 15:30 ` Andreas Arnez 2015-11-07 5:13 ` Jeff Law 2015-11-09 15:36 ` Andreas Krebbel 2015-11-04 16:18 ` [PATCH v3 2/2] [PR debug/67192] Further fix " Andreas Arnez 2015-11-07 5:15 ` Jeff Law 2015-11-09 17:59 ` Andreas Arnez 2015-11-09 15:36 ` Andreas Krebbel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).