[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-05-04 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #18 from Jakub Jelinek  ---
Fixed for 10.5 too.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-05-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #17 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:5589bb8d1fd3d4ecfb71e764d54bf931a743b85d

commit r10-11346-g5589bb8d1fd3d4ecfb71e764d54bf931a743b85d
Author: Jakub Jelinek 
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  

PR tree-optimization/107997
* tree-ssa-loop-ivopts.c: Include cfganal.h.
(create_new_iv) : 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)

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-05-03 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #16 from Jakub Jelinek  ---
Fixed for 11.4 as well.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-05-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #15 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed

commit r11-10687-g5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed
Author: Jakub Jelinek 
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  

PR tree-optimization/107997
* tree-ssa-loop-ivopts.c: Include cfganal.h.
(create_new_iv) : 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)

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-02-10 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #14 from Jakub Jelinek  ---
Fixed for gcc 12.3 too.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2023-02-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:89daf0dd6f1748077c03fbeb27ca5980a0b9abd5

commit r12-9125-g89daf0dd6f1748077c03fbeb27ca5980a0b9abd5
Author: Jakub Jelinek 
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  

PR tree-optimization/107997
* tree-ssa-loop-ivopts.cc: Include cfganal.h.
(create_new_iv) : 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)

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-14 Thread jbglaw--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jan-Benedict Glaw  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Jan-Benedict Glaw  ---
Fixed with that commit. There is a similar unrelated (PR108095), but that's got
its own ticket.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:7676235f690e624b7ed41a22b22ce8ccfac1492f

commit r13-4594-g7676235f690e624b7ed41a22b22ce8ccfac1492f
Author: Jakub Jelinek 
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  

PR tree-optimization/107997
* tree-ssa-loop-ivopts.cc: Include cfganal.h.
(create_new_iv) : 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.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-09 Thread jbglaw--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #10 from Jan-Benedict Glaw  ---
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.)

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-09 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from Jakub Jelinek  ---
Created attachment 54053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54053=edit
gcc13-pr107997.patch

Untested fix.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-08 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #8 from Jakub Jelinek  ---
Indeed, and it started with r10-5288-g52dc9c32311e8ea4833b8865c0d3121cad03937d
but guess it has been latent before.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

2022-12-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.1.0, 12.2.0
  Known to work||9.1.0
   Keywords||ice-checking
 Target|powerpc64-linux |x86_64-linux-gnu
   ||powerpc64-linux
Summary|[13 Regression] |[10/11/12/13 Regression]
   |r13-4389-gfd8dd6c0384969|r13-4389-gfd8dd6c0384969
   |probably uncovered an issue |probably uncovered an issue
   |building the Linux kernel   |building the Linux kernel
   Target Milestone|13.0|10.5

--- Comment #7 from Andrew Pinski  ---
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`.