Following causes ICE: $ s390x-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c -O /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c: In function ‘main’: /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c:12:1: error: insn does not satisfy its constraints: 12 | } | ^ (insn 17 9 14 2 (set (reg/f:DI 1 %r1 [65]) (plus:DI (unspec:DI [ (symbol_ref/u:DI ("*.LC0") [flags 0x2]) (reg:DI 5 %r5) ] UNSPEC_LTREF) (const_int 16 [0x10]))) "/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c":12:1 1269 {*movdi_64} (expr_list:REG_DEAD (reg:DI 5 %r5) (expr_list:REG_EQUIV (const:DI (plus:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) (const_int 16 [0x10]))) (nil)))) during RTL pass: cprop_hardreg /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr59037.c:12:1: internal compiler error: in extract_constrain_insn, at recog.c:2206 0x55d382 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/rtl-error.c:108 0x55d3a8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/rtl-error.c:118 0x55c8ae extract_constrain_insn(rtx_insn*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/recog.c:2206 0x97b007 copyprop_hardreg_forward_1 /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regcprop.c:801 0x97bb74 execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regcprop.c:1307
Caused by r265490. Ilya please have a look.
This must have slipped through, because I tested the movdi patch on top of the outdated trunk (r264877). Candidate fix: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01793.html
Author: iii Date: Tue Nov 6 13:20:21 2018 New Revision: 265844 URL: https://gcc.gnu.org/viewcvs?rev=265844&root=gcc&view=rev Log: S/390: Introduce relative_long attribute In order to properly fix PR87762, we need to distinguish between instructions which support relative addressing and instructions which don't. We could check whether the existing "type" attribute is equal to "larl", but there are notable exceptions (lrl, for example), and changing them makes scheduling worse on z10. We could also check whether the existing "op_type" attribute is equal to "RIL-b" or "RIL-c". However, adding a new attribute provides more flexibility, since we don't depend idiosyncrasies which might be introduced into PoP in the future. gcc/ChangeLog: 2018-11-06 Ilya Leoshkevich <iii@linux.ibm.com> PR target/87762 * config/s390/s390.md: Add relative_long attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.md
Author: iii Date: Fri Nov 9 20:33:19 2018 New Revision: 265991 URL: https://gcc.gnu.org/viewcvs?rev=265991&root=gcc&view=rev Log: S/390: Allow relative addressing of literal pool entries r265490 allowed the compiler to choose in a more flexible way whether to use load or load-address-relative-long (LARL) instruction. When it chose LARL for literal pool references, the latter ones were rewritten by pass_s390_early_mach to use UNSPEC_LTREF, which assumes base register usage, which in turn is not compatible with LARL. The end result was an ICE because of unrecognizable insn. UNSPEC_LTREF and friends are necessary in order to communicate the dependency on the base register to pass_sched2. When relative addressing is used, no base register is necessary, so in such cases the rewrite must be avoided. gcc/ChangeLog: 2018-11-09 Ilya Leoshkevich <iii@linux.ibm.com> PR target/87762 * config/s390/s390.c (s390_safe_relative_long_p): New function. (annotate_constant_pool_refs): Skip insns which support relative addressing. (annotate_constant_pool_refs_1): New helper function. (find_constant_pool_ref): Skip insns which support relative addression. (find_constant_pool_ref_1): New helper function. (replace_constant_pool_ref): Skip insns which support relative addressing. (replace_constant_pool_ref_1): New helper function. (s390_mainpool_start): Adapt to the new signature. (s390_mainpool_finish): Likewise. (s390_chunkify_start): Likewise. (s390_chunkify_finish): Likewise. (pass_s390_early_mach::execute): Likewise. (s390_prologue_plus_offset): Likewise. (s390_emit_prologue): Likewise. (s390_emit_epilogue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
Martin, I believe I fixed this one. Could you please give it another try?
Fixed.