[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #9 from Segher Boessenkool --- I have a patch.
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Priority|P2 |P1 --- Comment #8 from Segher Boessenkool --- Moving this to P1. See comment 4.
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P2
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #7 from Segher Boessenkool --- *** Bug 88863 has been marked as a duplicate of this bug. ***
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #6 from Segher Boessenkool --- *** Bug 88618 has been marked as a duplicate of this bug. ***
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #5 from Segher Boessenkool --- 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 target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2018-11-16 00:00:00 |2018-11-22 Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- 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?
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- 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).
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #2 from Martin Liška --- $ 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
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #1 from Segher Boessenkool --- It does not fail for me.
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Martin Liška changed: What|Removed |Added Target||ppc64le-linux-gnu Last reconfirmed||2018-11-16 Host||x86_64-pc-linux-gnu Target Milestone|--- |9.0
