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 <sa...@gcc.gnu.org>: https://gcc.gnu.org/g:a797398cfbc75899fdb7d97436c0c89c02b133c0 commit r15-1175-ga797398cfbc75899fdb7d97436c0c89c02b133c0 Author: Roger Sayle <ro...@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 <ro...@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.
