| Summary: | [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Jan-Benedict Glaw <jbglaw> |
| Component: | tree-optimization | Assignee: | Jakub Jelinek <jakub> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jakub, jbglaw, marxin, rguenth |
| Priority: | P3 | Keywords: | ice-checking, ice-on-valid-code |
| Version: | 13.0 | ||
| Target Milestone: | 10.5 | ||
| Host: | Target: | x86_64-linux-gnu powerpc64-linux | |
| Build: | Known to work: | 9.1.0 | |
| Known to fail: | 10.1.0, 11.1.0, 12.2.0 | Last reconfirmed: | 2022-12-08 00:00:00 |
| Attachments: |
Original preprocessed source
Reduced testcase (cvise) gcc13-pr107997.patch |
||
|
Description
Jan-Benedict Glaw
2022-12-06 22:24:13 UTC
(In reply to Jan-Benedict Glaw from comment #0) > I'll add the preprocessed sources. Could you please? Without it there isn't much that can be done. (In reply to Jakub Jelinek from comment #1) > (In reply to Jan-Benedict Glaw from comment #0) > > I'll add the preprocessed sources. > > Could you please? Without it there isn't much that can be done. At it right now, throwing it at cvise. Created attachment 54048 [details]
Original preprocessed source
Created attachment 54049 [details]
Reduced testcase (cvise)
Cleaned up, just -Os is needed:
int a, b;
void bar (int);
int baz (void);
void *
foo (int x, void *y)
{
asm goto ("" : : "r" (x || !a) : : l);
l:
if (y)
return 0;
bar (b ? b : x);
while (x--)
{
if (!baz ())
baz ();
asm goto ("" : : : : l2);
l2:
}
return y;
}
create_new_iv is called with cand->pos being IP_END, where the last stmt of the body is asm goto.
__asm__ __volatile__ goto("" : : : : "l2" l2);
;; succ: 13
;; basic block 13, loop depth 1
;; pred: 9
;; 12
# x_4 = PHI <x_10(D)(9), x_14(12)>
l2:
As the label is in the same bb as fallthrough, the bb which ends with asm goto has just a single succ edge, but in order to insert something at the end of the latch bb,
we would need to create a new bb, move the label to it and insert the iv there.
I guess gsi_insert_on_edge_immediate should be able to handle that case, or
perhaps just detect when gsi_last_bb (ip_end_pos (data->current_loop))
is GIMPLE_ASM or better yet stmt_ends_bb_p and split_edge in that case?
With the reduced testcase in comment #5 (with a `;` add after `l2:` to allow compiling with older gcc), the ICE is there for GCC 10+ (with -fchecking). GCC 9 didn't ICE nor did it place gimple after the `asm goto`. Indeed, and it started with r10-5288-g52dc9c32311e8ea4833b8865c0d3121cad03937d but guess it has been latent before. Created attachment 54053 [details] gcc13-pr107997.patch Untested fix. I gave that patch a try: GCC build is successful, as is the Linux build afterwards using that toolchain. (Cannot test the resulting kernel of course---I don't have the hardware.) The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:7676235f690e624b7ed41a22b22ce8ccfac1492f commit r13-4594-g7676235f690e624b7ed41a22b22ce8ccfac1492f Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107997 * tree-ssa-loop-ivopts.cc: Include cfganal.h. (create_new_iv) <case IP_END>: If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. Fixed with that commit. There is a similar unrelated (PR108095), but that's got its own ticket. The releases/gcc-12 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:89daf0dd6f1748077c03fbeb27ca5980a0b9abd5 commit r12-9125-g89daf0dd6f1748077c03fbeb27ca5980a0b9abd5 Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107997 * tree-ssa-loop-ivopts.cc: Include cfganal.h. (create_new_iv) <case IP_END>: If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f) Fixed for gcc 12.3 too. The releases/gcc-11 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed commit r11-10687-g5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107997 * tree-ssa-loop-ivopts.c: Include cfganal.h. (create_new_iv) <case IP_END>: If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f) Fixed for 11.4 as well. The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:5589bb8d1fd3d4ecfb71e764d54bf931a743b85d commit r10-11346-g5589bb8d1fd3d4ecfb71e764d54bf931a743b85d Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107997 * tree-ssa-loop-ivopts.c: Include cfganal.h. (create_new_iv) <case IP_END>: If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f) Fixed for 10.5 too. |