[Bug tree-optimization/113462] New: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[Bug tree-optimization/113462] New: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[zsojka at seznam dot cz]

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

            Bug ID: 113462
           Summary: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at
                    -O with _BitInt() in a struct
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in handle_cast, at
gimple-lower-bitint.cc:1539
    2 | foo(void)
      | ^~~
0xd88dea handle_cast
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1539
0x27092c0 handle_operand
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:815
0x27141fd lower_mergeable_stmt
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2481
0x271914d lower_stmt
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5339
0x271bb69 gimple_lower_bitint
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6534
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240117 (experimental) (GCC)

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is
  _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
unfolded from fre3.  Wonder if the best action wouldn't be trying to fold_stmt
such statements in the bitint lowering preparation code if we run into them.

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[jakub at gcc dot gnu.org]

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

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
   Last reconfirmed|                            |2024-01-19
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57164&action=edit
gcc14-pr113462.patch

Untested fix.

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC 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:efc677f3e78abf02264e4a64c751b4ecdc918ec9

commit r14-8303-gefc677f3e78abf02264e4a64c751b4ecdc918ec9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Jan 20 12:36:32 2024 +0100

    lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]

    The following patch ICEs because fre3 leaves around unfolded
      _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
    statement and in handle_cast I was expecting just SSA_NAMEs for the
    large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
    we can handle in that case exactly the same, as the handle_operand
recursion
    handles those.

    Of course, maybe we should also try to fold_stmt such cases somewhere in
    bitint lowering preparation.

    2024-01-20  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/113462
            * gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
            Handle rhs1 INTEGER_CST like SSA_NAME.

            * gcc.dg/bitint-76.c: New test.

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from GCC 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:5015015ae6b29b3f1734c7693ba25b88cdd531a1

commit r14-8349-g5015015ae6b29b3f1734c7693ba25b88cdd531a1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jan 23 09:02:48 2024 +0100

    fold-const: Fold larger VIEW_CONVERT_EXPRs [PR113462]

    On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
    > We run into
    >
    > static tree
    > native_interpret_int (tree type, const unsigned char *ptr, int len)
    > {
    > ...
    >   if (total_bytes > len
    >       || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT)
    >     return NULL_TREE;
    >
    > OTOH using a V_C_E to "truncate" a _BitInt looks wrong?  OTOH the
    > check doesn't really handle native_encode_expr using the "proper"
    > wide_int encoding however that's exactly handled.  So it might be
    > a pre-existing issue that's only uncovered by large _BitInts
    > (__int128 might show similar issues?)

    I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT
    conditions make no sense, all we care is whether it fits in the buffer
    or not.
    But then there is
    fold_view_convert_expr
    (and other spots) which use
      /* We support up to 1024-bit values (for GCN/RISC-V V128QImode).  */
      unsigned char buffer[128];
    or something similar.
    This patch fixes even that by using a XALLOCAVEC allocated buffer
    if the type size is 129 .. 8192 bytes.

    2024-01-22  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/113462
            * fold-const.cc (native_interpret_int): Don't punt if total_bytes
            is larger than HOST_BITS_PER_DOUBLE_INT / BITS_PER_UNIT.
            (fold_view_convert_expr): Use XALLOCAVEC buffers for types with
            sizes between 129 and 8192 bytes.