[Bug tree-optimization/113297] New: during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[Bug tree-optimization/113297] New: during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[zsojka at seznam dot cz]

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

            Bug ID: 113297
           Summary: during GIMPLE pass: esra ICE: in
                    smallest_mode_for_size, at stor-layout.cc:356 with
                    _BitInt() with -fstack-check=generic
           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
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-fre --param=large-stack-frame=1024
-fstack-check=generic testcase.c
during GIMPLE pass: esra
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.cc:356
   13 | }
      | ^
0x14f9f6f smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
        /repo/gcc-trunk/gcc/stor-layout.cc:356
0x14fe8b5 smallest_int_mode_for_size(poly_int<1u, unsigned long>)
        /repo/gcc-trunk/gcc/machmode.h:916
0x14fe8b5 layout_type(tree_node*)
        /repo/gcc-trunk/gcc/stor-layout.cc:2406
0x1828791 build_nonstandard_integer_type(unsigned long, int)
        /repo/gcc-trunk/gcc/tree.cc:7131
0x15fd950 analyze_access_subtree
        /repo/gcc-trunk/gcc/tree-sra.cc:2745
0x16037dd analyze_access_trees
        /repo/gcc-trunk/gcc/tree-sra.cc:2807
0x16037dd analyze_all_variable_accesses
        /repo/gcc-trunk/gcc/tree-sra.cc:3695
0x16037dd perform_intra_sra
        /repo/gcc-trunk/gcc/tree-sra.cc:4952
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-7023-20240109134751-gab6224dfe12-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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-7023-20240109134751-gab6224dfe12-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240109 (experimental) (GCC)

[Bug tree-optimization/113297] during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I don't know enough about SRA, obviously using
build_nonstandard_integer_type is invalid when the precision (root->size in
this case) is too large.

--- gcc/tree-sra.cc.jj  2024-01-03 11:51:35.054682295 +0100
+++ gcc/tree-sra.cc     2024-01-09 19:50:42.911500487 +0100
@@ -2733,7 +2733,8 @@ analyze_access_subtree (struct access *r
          For integral types this means the precision has to match.
         Avoid assumptions based on the integral type kind, too.  */
       if (INTEGRAL_TYPE_P (root->type)
-         && (TREE_CODE (root->type) != INTEGER_TYPE
+         && ((TREE_CODE (root->type) != INTEGER_TYPE
+              && TREE_CODE (root->type) != BITINT_TYPE)
              || TYPE_PRECISION (root->type) != root->size)
          /* But leave bitfield accesses alone.  */
          && (TREE_CODE (root->expr) != COMPONENT_REF
@@ -2742,8 +2743,11 @@ analyze_access_subtree (struct access *r
          tree rt = root->type;
          gcc_assert ((root->offset % BITS_PER_UNIT) == 0
                      && (root->size % BITS_PER_UNIT) == 0);
-         root->type = build_nonstandard_integer_type (root->size,
-                                                      TYPE_UNSIGNED (rt));
+         if (TREE_CODE (root->type) == BITINT_TYPE)
+           root->type = build_bitint_type (root->size, TYPE_UNSIGNED (rt));
+         else
+           root->type = build_nonstandard_integer_type (root->size,
+                                                        TYPE_UNSIGNED (rt));
          root->expr = build_ref_for_offset (UNKNOWN_LOCATION, root->base,
                                             root->offset, root->reverse,
                                             root->type, NULL, false);

fixes the ICE and obviously for original BITINT_TYPE we probably want to use
BITINT_TYPE, for non-BITINT_TYPE INTEGER_TYPE.  But it is unclear if the above
can't run into unsupportable cases, either if root->size would be too small
(BITINT_TYPE is only supported for precision 2 and above if signed, there is no
signed _BitInt(1)) and
more importantly on the other boundary.  __BITINT_MAXWIDTH__ is right now (on
x86-64 where it is only supported for now) 65535 bits, so {,un}signed
_BitInt(65535) is valid, but not _BitInt(65536).  As the above code doesn't
have some clear way to punt, I think something else needs to punt instead of
trying to build something for root->size 65536 - TYPE_PRECISION is only 16-bit,
so we can't have TYPE_PRECISION 65536...

[Bug tree-optimization/113297] during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |14.0

[Bug tree-optimization/113297] during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
another option might be to punt for _BitInt

[Bug tree-optimization/113297] during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2611cdc329e0229330b228e441934f386d6d5ff7

commit r14-7095-g2611cdc329e0229330b228e441934f386d6d5ff7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 10 12:46:00 2024 +0100

    sra: Partial fix for BITINT_TYPEs [PR113120]

    As changed in other parts of the compiler, using
    build_nonstandard_integer_type is not appropriate for arbitrary precisions,
    especially if the precision comes from a BITINT_TYPE or something based on
    that, build_nonstandard_integer_type relies on some integral mode being
    supported that can support the precision.

    The following patch uses build_bitint_type instead for BITINT_TYPE
    precisions.

    Note, it would be good if we were able to punt on the optimization
    (but this code doesn't seem to be able to punt, so it needs to be done
    somewhere earlier) at least in cases where building it would be invalid.
    E.g. right now BITINT_TYPE can support precisions up to 65535 (inclusive),
    but 65536 will not work anymore (we can't have > 16-bit TYPE_PRECISION).
    I've tried to replace 513 with 65532 in the testcase and it didn't ICE,
    so maybe it ran into some other SRA limit.

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

            PR tree-optimization/113120
            * tree-sra.cc (analyze_access_subtree): For BITINT_TYPE
            with root->size TYPE_PRECISION don't build anything new.
            Otherwise, if root->type is a BITINT_TYPE, use build_bitint_type
            rather than build_nonstandard_integer_type.

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

[Bug tree-optimization/113297] during GIMPLE pass: esra ICE: in smallest_mode_for_size, at stor-layout.cc:356 with _BitInt() with -fstack-check=generic

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:d790565afa219a2b38cd74f419b3e56d9ed6f5a4

commit r14-7100-gd790565afa219a2b38cd74f419b3e56d9ed6f5a4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 10 13:32:56 2024 +0100

    testsuite: Fix PR number [PR113297]

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

            PR tree-optimization/113297
            * gcc.dg/bitint-63.c: Fix PR number.