Following is causing ICE: $ cat ice.i int a; void b() { __builtin_sinh(a); __builtin_sinhf(a); __builtin_sinhl(a); } $ ppc64le-linux-gnu-gcc -fno-tree-dce -fno-tree-forwprop -Ofast ice.i ice.i: In function ‘b’: ice.i:6:1: error: unrecognizable insn: 6 | } | ^ (insn 11 10 12 2 (set (reg:DI 135) (unlt:DI (reg:CCFP 134) (const_int 0 [0]))) -1 (nil)) during RTL pass: vregs ice.i:6:1: internal compiler error: in extract_insn, at recog.c:2305 0x574aef _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:108 0x574b0b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:116 0x573ff8 extract_insn(rtx_insn*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2305 0x7c2e1f instantiate_virtual_regs_in_insn /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1605 0x7c2e1f instantiate_virtual_regs /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1975 0x7c2e1f execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:2024
It does not fail for me.
$ ppc64le-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/../libexec/gcc/ppc64le-linux-gnu/9.0.0/lto-wrapper Target: ppc64le-linux-gnu Configured with: /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/configure --enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/dev/shm/buildbot/install/gcc --target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as Thread model: posix gcc version 9.0.0 20181115 (experimental) 17a6cd1e22ad392b8dbdfa2db2fcb8311f299b55 (GCC) $ /usr/bin/powerpc64le-suse-linux-as -v GNU assembler version 2.31 (powerpc64le-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.31
I also see it when compiling gcc/testsuite/gcc.dg/pr37353.c for 32-bit BE powerpc: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -O1 -ffinite-math-only -fno-tree-forwprop -fno-tree-ter -c gcc/testsuite/gcc.dg/pr37353.c -o /dev/null gcc/testsuite/gcc.dg/pr37353.c: In function 'foo': gcc/testsuite/gcc.dg/pr37353.c:15:1: error: unrecognizable insn: 15 | } | ^ (insn 10 9 11 2 (set (reg:SI 127) (unlt:SI (reg:CCFP 128) (const_int 0 [0]))) -1 (nil)) during RTL pass: vregs gcc/testsuite/gcc.dg/pr37353.c:15:1: internal compiler error: in extract_insn, at recog.c:2305 0x639917 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:108 0x639935 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:116 0x637d86 extract_insn(rtx_insn*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/recog.c:2305 0xa2dbf2 instantiate_virtual_regs_in_insn /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1605 0xa2dbf2 instantiate_virtual_regs /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1975 0xa2dbf2 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:2024 (as of r266255).
Confirmed the comment 2 example. What happens is that rs6000_generate_compare (and all of the rs6000 backend in fact) does not handle UNLT (and similar) if flag_finite_math_only is true. But tree-call-cdce.c:gen_conditions_for_domain unconditionally generates them. Should the backend be changed? Note these conditions are pretty useless, they will always be optimised away again. Or should the tree-call-cdce code (as well as anything else) not generate those codes if flag_finite_math_only?
See rs6000.c:validate_condition_mode. This is: r36191 (from 2000), original; r39610 (from 2001), -ffast-math; r40300 (from 2001), -funsafe-math-optimizations; r55904 (from 2002), -ffinite-math-only. So it took some time to get it to this, but that is all ages ago. Should there be UNLT during gimple, even with -ffinite-math-only? Should expand then convert that do something saner already? Or should it not be generated in gimple either?
*** Bug 88618 has been marked as a duplicate of this bug. ***
*** Bug 88863 has been marked as a duplicate of this bug. ***
Moving this to P1. See comment 4.
I have a patch.
Author: segher Date: Fri Apr 19 16:58:01 2019 New Revision: 270460 URL: https://gcc.gnu.org/viewcvs?rev=270460&root=gcc&view=rev Log: tree-call-cdce: If !HONOR_NANS do not make code with NaNs (PR88055) If we don't HONOR_NANS we should not try to use any unordered comparison results. Best case those will just be optimized away; realistically, they ICE. For example, the rs6000 backend has some code that specifically checks we never do this. PR tree-optimization/88055 * tree-call-cdce.c (comparison_code_if_no_nans): New function. (gen_one_condition): Use it if !HONOR_NANS. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-call-cdce.c
Fixed.