[Bug regression/107997] New: fd8dd6c03849691 probably uncovered an issue building the Linux kernel

[Bug regression/107997] New: fd8dd6c03849691 probably uncovered an issue building the Linux kernel

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

            Bug ID: 107997
           Summary: fd8dd6c03849691 probably uncovered an issue building
                    the Linux kernel
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbglaw@lug-owl.de
  Target Milestone: ---

Hi!

Starting with commit fd8dd6c0384969170e594be34da278a072d5eb76, I see
Linux kernel build errors for the skiroot_defconfig:

[mk all 2022-12-05 19:50:10]   powerpc64-linux-gcc
-Wp,-MMD,drivers/dma-buf/.dma-fence-array.o.d -nostdinc
-I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include
-I./arch/po
werpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h -include
./include/linux/kconfig.h -include 
./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc
-DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wall -Wundef
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-comm
on -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11
-mlittle-endian -m64 -msoft-float -pipe -mtraceback=no
 -mabi=elfv2 -mcmodel=medium -mno-pointers-to-nested-functions -mcpu=power8
-mtune=power10 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma
-fno-asynchronous-unwind-tables -mno-string 
-Wa,-maltivec -Wa,-mpower4 -Wa,-many -mno-strict-align -mlittle-endian
-mstack-protector-guard=tls -mstack-protector-guard-reg=r13
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-form
at-truncation -Wno-format-overflow -Wno-address-of-packed-member -Os
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-main -Wno-unused-but-set-variable -Wno-
unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function
-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5
-fno-strict-overflow -fno-stack-check -fconse
rve-stack -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned
-mstack-protector-guard-offset=2800   
-DKBUILD_MODFILE='"drivers/dma-buf/dma-fe
nce-array"' -DKBUILD_BASENAME='"dma_fence_array"'
-DKBUILD_MODNAME='"dma_fence_array"' -D__KBUILD_MODNAME=kmod_dma_fence_array -c
-o drivers/dma-buf/dma-fence-array.o drivers/dma-buf/dma-fenc
e-array.c                                                                       
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c: In function
'dma_fence_array_create':                                                       
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: error:
control flow in the middle of basic block 12                                    
[mk all 2022-12-05 19:50:10]   154 | struct dma_fence_array
*dma_fence_array_create(int num_fences,                                         
[mk all 2022-12-05 19:50:10]       |                        
^~~~~~~~~~~~~~~~~~~~~~                                                          
[mk all 2022-12-05 19:50:10] during GIMPLE pass: ivopts                         
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: internal
compiler error: verify_flow_info failed                                         
[mk all 2022-12-05 19:50:10] 0x19ea876 internal_error(char const*, ...)         
[mk all 2022-12-05 19:50:10]    ???:0                                           
[mk all 2022-12-05 19:50:10] 0x94b00e verify_flow_info()                        
[mk all 2022-12-05 19:50:10]    ???:0                                           
[mk all 2022-12-05 19:50:10] Please submit a full bug report, with preprocessed
source (by using -freport-bug).                                                 
[mk all 2022-12-05 19:50:10] Please include the complete backtrace with any bug
report.                                                                         
[mk all 2022-12-05 19:50:10] See <https://gcc.gnu.org/bugs/> for instructions.  


(Cf. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607874.html)

I'll add the preprocessed sources.

[Bug tree-optimization/107997] [13 Regression] fd8dd6c03849691 probably uncovered an issue building the Linux kernel

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
          Component|regression                  |tree-optimization
            Summary|fd8dd6c03849691 probably    |[13 Regression]
                   |uncovered an issue building |fd8dd6c03849691 probably
                   |the Linux kernel            |uncovered an issue building
                   |                            |the Linux kernel
   Target Milestone|---                         |13.0
             Target|                            |powerpc64-linux

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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.

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

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #2 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
(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.

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

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #3 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
Created attachment 54048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54048&action=edit
Original preprocessed source

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

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #4 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
Created attachment 54049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54049&action=edit
Reduced testcase (cvise)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-08
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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;
}

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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?

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
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`.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
Created attachment 54053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54053&action=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

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #10 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

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

[jbglaw@lug-owl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Jan-Benedict Glaw <jbglaw@lug-owl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.5 too.