[Bug target/115397] New: [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[Bug target/115397] New: [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[slyfox at gcc dot gnu.org]

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

            Bug ID: 115397
           Summary: [15 Regression]  ICE 'during RTL pass: split1' on
                    numpy-1.26.4 i686-linux '-fPIC -mavx512f'
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed on gcc master from r15-1111-ge22b7f741ab54f today. There numpy on
i686-linux ICEs. Extracted example:

// $ cat bug.c.c
int LONG_divide_AVX512F_dimensions_0;
void npy_set_floatstatus_overflow();
void LONG_divide_AVX512F() {
  long *src;
  int raise_err = 0;
  for (; LONG_divide_AVX512F_dimensions_0;
       --LONG_divide_AVX512F_dimensions_0, ++src) {
    long a = *src;
    if (a)
      raise_err = 1;
  }
  if (raise_err)
    npy_set_floatstatus_overflow();
}

Crashing:

$ gcc -std=c99 -fPIC   -mavx512f -c bug.c.c -o bug.o -O3
during RTL pass: split1
bug.c.c: In function 'LONG_divide_AVX512F':
bug.c.c:14:1: internal compiler error: Segmentation fault
   14 | }
      | ^
0x9a3deba diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, char**, diagnostic_t)
        ???:0
0x9a3e33c internal_error(char const*, ...)
        ???:0
0x898434a crash_signal(int)
        ???:0
0x8329133 get_pool_constant(rtx_def const*) [clone .cold]
        ???:0
0x8dbcd04 ix86_broadcast_from_constant(machine_mode, rtx_def*)
        ???:0
0x8ddee5c ix86_expand_ternlog(machine_mode, rtx_def*, rtx_def*, rtx_def*, int,
rtx_def*)
        ???:0
0x937cdc7 gen_split_1359(rtx_insn*, rtx_def**)
        ???:0
0x95a1992 split_70(rtx_def*, rtx_insn*) [clone .isra.0]
        ???:0
0x977abbb split_73(rtx_def*, rtx_insn*)
        ???:0
0x85793de try_split(rtx_def*, rtx_insn*, int)
        ???:0
0x88e8db6 split_insn(rtx_insn*)
        ???:0
0x88ee33e split_all_insns()
        ???:0
0x88ee3f7 (anonymous namespace)::pass_split_all_insns::execute(function*)
        ???:0
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.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<<NIX>>/gfortran-15.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<<NIX>>/gfortran-15.0.0/libexec/gcc/i686-unknown-linux-gnu/15.0.0/lto-wrapper
Target: i686-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<<NIX>>/gfortran-15.0.0
--with-gmp-include=/<<NIX>>/gmp-6.3.0-dev/include
--with-gmp-lib=/<<NIX>>/gmp-6.3.0/lib
--with-mpfr-include=/<<NIX>>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<<NIX>>/mpfr-4.2.1/lib --with-mpc=/<<NIX>>/libmpc-1.3.1
--with-native-system-header-dir=/<<NIX>>/glibc-2.39-52-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<<NIX>>/gfortran-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=fortran --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<<NIX>>/isl-0.20 --with-arch=i686
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
--target=i686-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 99999999 (experimental) (GCC)

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[slyfox at gcc dot gnu.org]

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

--- Comment #1 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Debug build of the compiler is slightly more informative:

$ gcc -std=c99 -O3 -mavx512f -c bug.c.c -m32 -fPIC -fchecking=2
during RTL pass: split1
bug.c.c: In function 'LONG_divide_AVX512F':
bug.c.c:14:1: internal compiler error: RTL flag check: CONSTANT_POOL_ADDRESS_P
used with unexpected rtx code 'plus' in get_pool_constant, at varasm.cc:4046
   14 | }
      | ^
0x806828 rtl_check_failed_flag(char const*, rtx_def const*, char const*, int,
char const*)
        ../../source/gcc/rtl.cc:853
0x88fa27 get_pool_constant(rtx_def const*)
        ../../source/gcc/varasm.cc:4046
0x15e2829 ix86_broadcast_from_constant(machine_mode, rtx_def*)
        ../../source/gcc/config/i386/i386-expand.cc:612
0x16061be ix86_expand_ternlog(machine_mode, rtx_def*, rtx_def*, rtx_def*, int,
rtx_def*)
        ../../source/gcc/config/i386/i386-expand.cc:26045
0x1cddbd5 gen_split_1548(rtx_insn*, rtx_def**)
        ../../source/gcc/config/i386/sse.md:13050
0x20fa245 split_75
        ../../source/gcc/config/i386/sse.md:13044
0x20fa245 split_79
        ../../source/gcc/config/i386/sse.md:14592
0xc220eb try_split(rtx_def*, rtx_insn*, int)
        ../../source/gcc/emit-rtl.cc:3941
0x100f217 split_insn
        ../../source/gcc/recog.cc:3405
0x1015077 split_all_insns()
        ../../source/gcc/recog.cc:3509
0x1015128 execute
        ../../source/gcc/recog.cc:4433

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[slyfox at gcc dot gnu.org]

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

--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Bisect arrived at r15-1100-gec985bc97a0157, looks relevant:

commit ec985bc97a01577bca8307f986caba7ba7633cde
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Fri Jun 7 13:57:23 2024 +0100

    i386: Improve handling of ternlog instructions in i386/sse.md

    This patch improves the way that the x86 backend recognizes and
    expands AVX512's bitwise ternary logic (vpternlog) instructions.

    ...

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manuel.lauss at googlemail dot com

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115398 has been marked as a duplicate of this bug. ***

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-linux-gnu
   Target Milestone|---                         |15.0
           Keywords|                            |ice-checking,
                   |                            |ice-on-valid-code
            Version|14.0                        |15.0

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-08
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #4 from Roger Sayle <roger at nextmovesoftware dot com> ---
Created attachment 58386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58386&action=edit
proposed patch

This patch appears to fix (or more accurately workaround) the issue with this
testcase.
The (immediate) constant operand is:
(const_vector:V8SI [
        (const_int 1 [0x1]) repeated x8
    ])
After the call to force_const_mem this becomes:
(mem/u/c:V8SI (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [0  S32 A256])
But after the call to validize_mem it becomes:
(mem/u/c:V8SI (plus:SI (reg:SI 98)
        (const:SI (unspec:SI [
                    (symbol_ref/u:SI ("*.LC1") [flags 0x2])
                ] UNSPEC_GOTOFF))) [0  S32 A256])

The call get_pool_constant (and ix86_broadcast_from_constant) can correctly
handle the intermediate form, but not the "validized" MEM.
Currently bootstrapping and regression testing...

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157

[slyfox at gcc dot gnu.org]

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

--- Comment #5 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #4)
> Created attachment 58386 [details]
> proposed patch
> 
> This patch appears to fix (or more accurately workaround) the issue with this
> testcase.

The change fixes the build for numpy-1.26.4 for me as well. Thank you!

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115407 has been marked as a duplicate of this bug. ***

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

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

commit r15-1175-ga797398cfbc75899fdb7d97436c0c89c02b133c0
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue Jun 11 09:31:34 2024 +0100

    i386: PR target/115397: AVX512 ternlog vs. -m32 -fPIC constant pool.

    This patch fixes PR target/115397, a recent regression caused by my
    ternlog patch that results in an ICE (building numpy) with -m32 -fPIC.
    The problem is that ix86_broadcast_from_constant, which calls
    get_pool_constant, doesn't handle the UNSPEC_GOTOFF that's created by
    calling validize_mem when using -fPIC on i686.  The logic here is a bit
    convoluted (and my future patches will clean some of this up), but the
    simplest fix is to call ix86_broadcast_from_constant between the calls
    to force_const_mem and the call to validize_mem.

    Perhaps a better solution might be to call targetm.delegitimize_address
    from the middle-end's get_pool_constant, but ultimately the best approach
    would be to not place things in the constant pool if we don't need to.
    My plans to move (broadcast) constant handling from expand to split1
    should simplify this.

    2024-06-11  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/115397
            * config/i386/i386-expand.cc (ix86_expand_ternlog): Move call to
            ix86_broadcast_from_constant before call to validize_mem, but after
            call to force_const_mem.

    gcc/testsuite/ChangeLog
            PR target/115397
            * gcc.target/i386/pr115397.c: New test case.

[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

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

--- Comment #8 from Roger Sayle <roger at nextmovesoftware dot com> ---
This issue should now be fixed on mainline.  We now generate better code on
i686 with -fPIC (for this case) than we did in GCC 14.