[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #18 from Martin Liška --- Maybe PR86684?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #17 from Bill Seurer --- Is there some earlier report to which this is a follow-on? The first comment here sort of implies that.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #16 from Martin Liška --- (In reply to Bill Seurer from comment #15) > Martin, are you expecting this build to have 64 bit or 128 bit long doubles? > The default should be 128 as it is natively but for some reason the cross > compiler is using 64. Even with that, though, the compiler shouldn't be > ICEing. Dunno. Note that the bug was reported by a fuzzer.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #15 from Bill Seurer --- Martin, are you expecting this build to have 64 bit or 128 bit long doubles? The default should be 128 as it is natively but for some reason the cross compiler is using 64. Even with that, though, the compiler shouldn't be ICEing. I tested and if you add --with--long-double-128 the cross compiler will behave the same as a native compiler and the ICE won't occur.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #14 from Bill Seurer ---
I compared what happens with long double and they are very different
int do_signbit_tf (long double a) { return __builtin_signbit (a); }
cross:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:DF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S8 A64])
(reg:DF 33 1 [ a ])) "./signbit-1-2.c":8:35 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:DI 119)
(mem/c:DI (reg/f:DI 112 virtual-stack-vars) [1 a+0 S8 A64]))
"./signbit-1-2.c":8:44 -1
(nil))
(insn 7 6 8 2 (set (reg:DI 120)
(lshiftrt:DI (reg:DI 119)
(const_int 63 [0x3f]))) "./signbit-1-2.c":8:44 -1
(nil))
(insn 8 7 9 2 (set (reg:SI 121)
(and:SI (subreg:SI (reg:DI 120) 0)
(const_int 1 [0x1]))) "./signbit-1-2.c":8:44 -1
(nil))
...etc...
native:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:TF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
A128])
(reg:TF 33 1 [ a ])) "./signbit-1-2.c":8:35 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:TF 120)
(mem/c:TF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16 A128]))
"./signbit-1-2.c":8:44 -1
(nil))
(insn 7 6 8 2 (set (reg:DF 121)
(float_truncate:DF (reg:TF 120))) "./signbit-1-2.c":8:44 -1
(nil))
...etc...
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #13 from Segher Boessenkool --- If both compilers default to ibmlongdouble, both should use TFmode, no?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #12 from Bill Seurer --- confgures are identical. Default compiler options are also identical, from -Q --help=target: The following options are target specific: -G0 -m32 [disabled] -m64 [enabled] -mabi=altivec [disabled] -mabi=d32 [enabled] -mabi=d64 [disabled] -mabi=elfv1 [disabled] -mabi=elfv2 [disabled] -mabi=ibmlongdouble [enabled] -mabi=ieeelongdouble [disabled] -mabi=no-altivec [enabled] -mads [disabled] -maix-struct-return [disabled] -malign- power -malign-branch-targets[enabled] -mallow-movmisalign [enabled] -maltivec [enabled] -malways-hint [enabled] -mavoid-indexed-addresses [enabled] -mbig [disabled] -mbig-endian [disabled] -mbionic [disabled] -mbit-align [disabled] -mbit-word[disabled] -mblock-compare-inline-limit= 63 -mblock-compare-inline-loop-limit=-1 -mblock-move-inline-limit=0 -mbss-plt [enabled] -mcall-ABI -mcmodel= small -mcmpb[enabled] -mcompat-align-parm [disabled] -mcpu=[default] -mcrypto [enabled] -mdebug= -mdirect-move [enabled] -mdlmzb [disabled] -meabi[disabled] -mefficient-unaligned-vsx [enabled] -memb [disabled] -mfloat128[disabled] -mfloat128-convert[disabled] -mfloat128-hardware [disabled] -mfold-gimple [enabled] -mfp-in-toc [enabled] -mfprnd [enabled] -mfriz[enabled] -mfull-toc[disabled] -mfused-madd -ffp-contract=fast -mfuture [disabled] -mgen-cell-microcode [ignored] -mglibc [enabled] -mgnu-attribute [enabled] -mhard-dfp[enabled] -mhard-float [enabled] -mhtm [enabled] -minsert-sched-nops= -misel[disabled] -mlittle [enabled] -mlittle-endian [enabled] -mlong-double-0 -mlongcall[disabled] -mlra [ignored] -mmfcrf [enabled] -mmfpgpr [disabled] -mminimal-toc [disabled] -mmodulo [disabled] -mmulhw [disabled] -mmultiple[disabled] -mmusl[disabled] -mmvme[disabled] -mnewlib [disabled] -mno-fp-in-toc[disabled] -mno-mfpgpr [ignored] -mno-string [ignored] -mno-sum-in-toc [disabled] -mno-toc [disabled] -mno-traceback[disabled] -mno-update [disabled] -moptimize-swaps [enabled] -mpcrel [disabled] -mpltseq [enabled] -mpointers-to-nested-functions[enabled] -mpopcntb [enabled] -mpopcntd [enabled] -mpower8-fusion [disabled] -mpower8-fusion-sign [disabled] -mpower8-vector [enabled] -mpower9-minmax [disabled] -mpower9-misc [disabled] -mpower9-vector [disabled] -mpowerpc [ignored] -mpowerpc-gfxopt [enabled] -mpowerpc-gpopt [enabled] -mpowerpc64 [enabled] -mprefixed
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #11 from Peter Bergner ---
(In reply to Bill Seurer from comment #8)
> Cross:
> ;;
> ;; Full RTL generated for this function:
> ;;
> (note 1 0 4 NOTE_INSN_DELETED)
> (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 2 4 3 2 (set (mem/c:IF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
> A128])
> (reg:IF 33 1 [ a ])) "./signbit-1.c":7:32 -1
> (nil))
I can get close to this with a native build using -O2 -mcpu=power8 -mfloat128
-mabi=ieeelongdouble, but I still don't see an ICE:
void
do_signbit_if (__ibm128 a)
{
volatile __ibm128 dst;
dst = a;
}
Full rtl:
(insn 2 4 3 2 (set (reg/v:IF 117 [ aD.2831 ])
(reg:IF 33 1 [ aD.2831 ])) "str.i":3:1 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 0 2 (set (mem/v/c:IF (reg/f:DI 112 virtual-stack-vars) [1 dstD.2834+0
S16 A128])
(reg/v:IF 117 [ aD.2831 ])) "str.i":5:7 -1
(nil))
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #10 from Peter Bergner --- (In reply to Segher Boessenkool from comment #9) > So what causes this TF vs. IF? Cross and native should be exactly the same, > but perhaps there is a difference in the configurations you have for the two? Maybe on native, our long double defaults to IBM long double and on a cross build we somehow default to IEEE float 128? I wonder if the native build ICEs when using -mfloat128 -mabi=ieeelongdouble ?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #9 from Segher Boessenkool --- So what causes this TF vs. IF? Cross and native should be exactly the same, but perhaps there is a difference in the configurations you have for the two?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
Bill Seurer changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
||seurer at linux dot
vnet.ibm.com
--- Comment #8 from Bill Seurer ---
I have duplicated the bug on a cross compile but not natively.
It occurs in the one function:
int do_signbit_if (__ibm128 a) { return __builtin_signbit (a); }
Natively this looks like this when dumped:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:TF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
A128])
(reg:TF 33 1 [ a ])) "./signbit-1.c":7:32 -1
(nil))
...
Cross:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:IF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
A128])
(reg:IF 33 1 [ a ])) "./signbit-1.c":7:32 -1
(nil))
...
Note the reg/mem differences. There are similar ones further on.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #7 from Martin Liška --- (In reply to Peter Bergner from comment #6) > (In reply to Peter Bergner from comment #5) > > (In reply to Martin Liška from comment #4) > > > Yep, I can still reproduce it with the current master in a cross compiler. > > > > Ok, thanks. I'll see if I can recreate it with a cross since I cannot get > > it to fail with a native build. > > I still cannot reproduce this even in a cross. What GCC and binutils > configure options did you use? I'll note, that I don't have ppc header > files to build against, so I cannot do a full bootstrap build, but I do get > far enough to get a cc1/xgcc to compile the test case with. I built it like this: $ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/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/10.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 Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20200109 (experimental) 51ad584fdbea7291b52f8b93d351ab3b51d405c9 (GCC) $ /usr/bin/powerpc64le-suse-linux-as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.33.1.20191023-2
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #6 from Peter Bergner --- (In reply to Peter Bergner from comment #5) > (In reply to Martin Liška from comment #4) > > Yep, I can still reproduce it with the current master in a cross compiler. > > Ok, thanks. I'll see if I can recreate it with a cross since I cannot get > it to fail with a native build. I still cannot reproduce this even in a cross. What GCC and binutils configure options did you use? I'll note, that I don't have ppc header files to build against, so I cannot do a full bootstrap build, but I do get far enough to get a cc1/xgcc to compile the test case with.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #5 from Peter Bergner --- (In reply to Martin Liška from comment #4) > Yep, I can still reproduce it with the current master in a cross compiler. Ok, thanks. I'll see if I can recreate it with a cross since I cannot get it to fail with a native build.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-08 Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Yep, I can still reproduce it with the current master in a cross compiler.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #3 from Peter Bergner --- Martin, can you please check whether you still see this ICE?
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #2 from Peter Bergner ---
This doesn't fail for me using a native build. Martin, can you recheck to see
if this is now fixed? There have been some changes in this area and I do see
that pattern in my dump file with no ICE:
(insn 6 3 7 2 (set (reg:DF 124)
(float_truncate:DF (reg/v:IF 122 [ aD.2830 ]))) "t.i":5:10 529
{truncifdf2_internal1}
(nil))
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #1 from Martin Liška --- /usr/bin/powerpc64le-suse-linux-as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.31 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `powerpc64le-suse-linux'.
