[Bug middle-end/111699] New: [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[Bug middle-end/111699] New: [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[zsojka at seznam dot cz]

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

            Bug ID: 111699
           Summary: [14 Regression] ICE: SIGSEGV: infinite recursion in
                    fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_
                    COND_EXPR
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: aarch64-unknown-linux-gnu

Created attachment 56054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56054&action=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc testcase.c -wrapper gdb,-q,--args
Reading symbols from
/repo/gcc-trunk/binary-trunk-20231005001818-gbf2e66e3ee2-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/cc1...
(gdb) r
Starting program:
/repo/gcc-trunk/binary-trunk-20231005001818-gbf2e66e3ee2-checking-yes-rtl-df-extra-aarch64/libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/cc1
-quiet -iprefix
/repo/gcc-trunk/binary-trunk-20231005001818-gbf2e66e3ee2-checking-yes-rtl-df-extra-aarch64/bin/../lib/gcc/aarch64-unknown-linux-gnu/14.0.0/
testcase.c -quiet -dumpdir a- -dumpbase testcase.c -dumpbase-ext .c
-mlittle-endian -mabi=lp64 -o /tmp/cc6LuKcc.s
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
const_binop (code=BIT_AND_EXPR, arg1=0x7ffff756a7c8, arg2=0x7ffff756a870) at
/repo/gcc-trunk/gcc/fold-const.cc:1358
1358      STRIP_NOPS (arg1);
(gdb) bt
#0  const_binop (code=BIT_AND_EXPR, arg1=0x7ffff756a7c8, arg2=0x7ffff756a870)
at /repo/gcc-trunk/gcc/fold-const.cc:1358
#1  0x0000000000ea0ee6 in const_binop (code=BIT_AND_EXPR, arg1=0x7ffff7212b70,
arg2=0x7ffff7213360) at /repo/gcc-trunk/gcc/fold-const.cc:1688
#2  0x0000000000e94ff1 in fold_binary_loc (loc=2147483651, code=<optimized
out>, type=0x7ffff7556498, op0=0x7ffff7212b70, op1=0x7ffff7213360) at
/repo/gcc-trunk/gcc/fold-const.cc:11129
#3  0x0000000000e9c7fb in fold_build2_loc (loc=2147483651, code=BIT_AND_EXPR,
type=0x7ffff7556498, op0=0x7ffff7212b70, op1=0x7ffff7213360) at
/repo/gcc-trunk/gcc/fold-const.cc:14040
#4  0x0000000000eae86d in fold_binary_op_with_conditional_arg (loc=2147483651,
code=BIT_AND_EXPR, type=0x7ffff7556498, op0=<optimized out>, op1=<optimized
out>, cond=<optimized out>, arg=<optimized out>, 
    cond_first_p=1) at /repo/gcc-trunk/gcc/fold-const.cc:7336
#5  0x0000000000e95062 in fold_binary_loc (loc=2147483651, code=<optimized
out>, type=0x7ffff7556498, op0=0x7ffff7557640, op1=0x7ffff7213360) at
/repo/gcc-trunk/gcc/fold-const.cc:11219
#6  0x0000000000e9c7fb in fold_build2_loc (loc=loc@entry=2147483651,
code=code@entry=BIT_AND_EXPR, type=0x7ffff7556498,
op0=op0@entry=0x7ffff7557640, op1=op1@entry=0x7ffff7213360)
    at /repo/gcc-trunk/gcc/fold-const.cc:14040
#7  0x00000000021f9843 in generic_simplify_VEC_COND_EXPR (loc=2147483651,
code=<optimized out>, type=0x7ffff7556348, _p0=0x7ffff7211bd0,
_p1=0x7ffff756a7e0, _p2=0x7ffff756a7f8) at generic-match-2.cc:8731
#8  0x0000000000eabf3b in fold_ternary_loc (loc=2147483651, code=VEC_COND_EXPR,
type=0x7ffff7556348, op0=0x7ffff7211bd0, op1=0x7ffff756a7e0,
op2=0x7ffff756a7f8) at /repo/gcc-trunk/gcc/fold-const.cc:13028
#9  0x0000000000eadeb8 in fold_build3_loc (loc=loc@entry=2147483651,
code=code@entry=VEC_COND_EXPR, type=type@entry=0x7ffff7556348,
op0=0x7ffff7211bd0, op1=op1@entry=0x7ffff756a7e0, 
    op2=op2@entry=0x7ffff756a7f8) at /repo/gcc-trunk/gcc/fold-const.cc:14100
#10 0x00000000021f985e in generic_simplify_VEC_COND_EXPR (loc=2147483651,
code=<optimized out>, type=0x7ffff7556348, _p0=0x7ffff7211ba0,
_p1=0x7ffff756a7e0, _p2=0x7ffff756a7f8) at generic-match-2.cc:8739
#11 0x0000000000eabf3b in fold_ternary_loc (loc=2147483651, code=VEC_COND_EXPR,
type=0x7ffff7556348, op0=0x7ffff7211ba0, op1=0x7ffff756a7e0,
op2=0x7ffff756a7f8) at /repo/gcc-trunk/gcc/fold-const.cc:13028
#12 0x0000000000eadeb8 in fold_build3_loc (loc=loc@entry=2147483651,
code=code@entry=VEC_COND_EXPR, type=type@entry=0x7ffff7556348,
op0=0x7ffff7211ba0, op1=op1@entry=0x7ffff756a7e0, 
    op2=op2@entry=0x7ffff756a7f8) at /repo/gcc-trunk/gcc/fold-const.cc:14100
...

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-13-branch/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-13-branch/binary-13-branch-20231001002158-gf8353d6a7cd-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.2.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-13-branch//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-13-branch//binary-13-branch-20231001002158-gf8353d6a7cd-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20231001 (GCC)

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection
   Target Milestone|---                         |14.0

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-05
             Target|aarch64-unknown-linux-gnu   |
             Status|UNCONFIRMED                 |NEW
               Host|x86_64-pc-linux-gnu         |
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a testcase which fails everywhere:
```
typedef unsigned char __attribute__((__vector_size__ (8))) V;

V
foo (V v)
{
  return (V) 0x107B9A7FF >= (v <= 0);
}
```

AARCH64 defaults to unsigned char which is why it fails there with the original
testcase.

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(simplify
 (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2)
 (if (optimize_vectors_before_lowering_p () && types_match (@0, @3))
  (vec_cond (bit_and @0 @3) @1 @2)))

goes into an infinite loop with fold_build3 as the fold_build2:BIT_AND of:
(gdb) p debug_generic_expr(captures[1])
v == { 0, 0, 0, 0, 0, 0, 0, 0 }
$9 = void
(gdb) p debug_generic_expr(captures[2])
{ 0, -1, -1, -1, -1, -1, -1, -1 }

Creates a vec_cond ...

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
this was exposed by my commit (r14-3350-g47b833a9abe1) which added:
/* Likewise for view_convert of nop_conversions. */
(simplify
 (view_convert (vec_cond:s @0 @1 @2))
 (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@1))
      && known_eq (TYPE_VECTOR_SUBPARTS (type),
                   TYPE_VECTOR_SUBPARTS (TREE_TYPE (@1)))
      && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE (@1))))
  (vec_cond @0 (view_convert! @1) (view_convert! @2))))

Before we have a VIEW_CONVERT around the vec_cond which prevented the infinite
loop but now we don't ...

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a patch.

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-October
                   |                            |/632128.html

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632128.html

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:e77428a9a336f57e3efe3eff95f2b491d7e9be14

commit r14-4432-ge77428a9a336f57e3efe3eff95f2b491d7e9be14
Author: Andrew Pinski <pinskia@gmail.com>
Date:   Thu Oct 5 12:21:19 2023 -0700

    MATCH: Fix infinite loop between `vec_cond(vec_cond(a,b,0), c, d)` and `a &
b`

    Match has a pattern which converts `vec_cond(vec_cond(a,b,0), c, d)`
    into `vec_cond(a & b, c, d)` but since in this case a is a comparison
    fold will change `a & b` back into `vec_cond(a,b,0)` which causes an
    infinite loop.
    The best way to fix this is to enable the patterns for
vec_cond(*,vec_cond,*)
    only for GIMPLE so we don't get an infinite loop for fold any more.

    Note this is a latent bug since these patterns were added in
r11-2577-g229752afe3156a
    and was exposed by r14-3350-g47b833a9abe1 where now able to remove a
VIEW_CONVERT_EXPR.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

            PR middle-end/111699

    gcc/ChangeLog:

            * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
            (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Enable only for GIMPLE.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/pr111699-1.c: New test.

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |13.3
      Known to work|13.2.1                      |10.4.0, 14.0
      Known to fail|14.0                        |

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Will be backporting it in a few days to the other open branches as this is a
latent bug.

[Bug middle-end/111699] [11/12/13 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Andrew Pinski
<pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:add2afa9e25f1776fdfbeb1b99fd1efcf850f91f

commit r13-7938-gadd2afa9e25f1776fdfbeb1b99fd1efcf850f91f
Author: Andrew Pinski <pinskia@gmail.com>
Date:   Thu Oct 5 12:21:19 2023 -0700

    MATCH: Fix infinite loop between `vec_cond(vec_cond(a,b,0), c, d)` and `a &
b`

    Match has a pattern which converts `vec_cond(vec_cond(a,b,0), c, d)`
    into `vec_cond(a & b, c, d)` but since in this case a is a comparison
    fold will change `a & b` back into `vec_cond(a,b,0)` which causes an
    infinite loop.
    The best way to fix this is to enable the patterns for
vec_cond(*,vec_cond,*)
    only for GIMPLE so we don't get an infinite loop for fold any more.

    Note this is a latent bug since these patterns were added in
r11-2577-g229752afe3156a
    and was exposed by r14-3350-g47b833a9abe1 where now able to remove a
VIEW_CONVERT_EXPR.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

            PR middle-end/111699

    gcc/ChangeLog:

            * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
            (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Enable only for GIMPLE.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/pr111699-1.c: New test.

    (cherry picked from commit e77428a9a336f57e3efe3eff95f2b491d7e9be14)

[Bug middle-end/111699] [11/12/13 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Andrew Pinski
<pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:a63238cd52d974d364677def97d4ed70d26a7410

commit r12-9915-ga63238cd52d974d364677def97d4ed70d26a7410
Author: Andrew Pinski <pinskia@gmail.com>
Date:   Thu Oct 5 12:21:19 2023 -0700

    MATCH: Fix infinite loop between `vec_cond(vec_cond(a,b,0), c, d)` and `a &
b`

    Match has a pattern which converts `vec_cond(vec_cond(a,b,0), c, d)`
    into `vec_cond(a & b, c, d)` but since in this case a is a comparison
    fold will change `a & b` back into `vec_cond(a,b,0)` which causes an
    infinite loop.
    The best way to fix this is to enable the patterns for
vec_cond(*,vec_cond,*)
    only for GIMPLE so we don't get an infinite loop for fold any more.

    Note this is a latent bug since these patterns were added in
r11-2577-g229752afe3156a
    and was exposed by r14-3350-g47b833a9abe1 where now able to remove a
VIEW_CONVERT_EXPR.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

            PR middle-end/111699

    gcc/ChangeLog:

            * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
            (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Enable only for GIMPLE.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/pr111699-1.c: New test.

    (cherry picked from commit e77428a9a336f57e3efe3eff95f2b491d7e9be14)

[Bug middle-end/111699] [11/12/13 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Andrew Pinski
<pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:9d4caf90e7bf1824ebabf0bc0541bfea511ef03b

commit r11-11054-g9d4caf90e7bf1824ebabf0bc0541bfea511ef03b
Author: Andrew Pinski <pinskia@gmail.com>
Date:   Thu Oct 5 12:21:19 2023 -0700

    MATCH: Fix infinite loop between `vec_cond(vec_cond(a,b,0), c, d)` and `a &
b`

    Match has a pattern which converts `vec_cond(vec_cond(a,b,0), c, d)`
    into `vec_cond(a & b, c, d)` but since in this case a is a comparison
    fold will change `a & b` back into `vec_cond(a,b,0)` which causes an
    infinite loop.
    The best way to fix this is to enable the patterns for
vec_cond(*,vec_cond,*)
    only for GIMPLE so we don't get an infinite loop for fold any more.

    Note this is a latent bug since these patterns were added in
r11-2577-g229752afe3156a
    and was exposed by r14-3350-g47b833a9abe1 where now able to remove a
VIEW_CONVERT_EXPR.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

            PR middle-end/111699

    gcc/ChangeLog:

            * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
            (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Enable only for GIMPLE.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/pr111699-1.c: New test.

    (cherry picked from commit e77428a9a336f57e3efe3eff95f2b491d7e9be14)

[Bug middle-end/111699] [11/12/13 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |12.3.1, 13.2.1
         Resolution|---                         |FIXED
   Target Milestone|13.3                        |11.5

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed everywhere.