* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-27 23:03 ` seurer at linux dot vnet.ibm.com
2020-03-28 20:12 ` segher at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-03-27 23:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
Bill Seurer <seurer at linux dot vnet.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |meissner at gcc dot gnu.org,
| |seurer at linux dot vnet.ibm.com
--- Comment #8 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
2020-03-27 23:03 ` [Bug target/87163] ICE in extract_insn, at recog.c:2305 seurer at linux dot vnet.ibm.com
@ 2020-03-28 20:12 ` segher at gcc dot gnu.org
2020-03-28 22:28 ` bergner at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-03-28 20:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
2020-03-27 23:03 ` [Bug target/87163] ICE in extract_insn, at recog.c:2305 seurer at linux dot vnet.ibm.com
2020-03-28 20:12 ` segher at gcc dot gnu.org
@ 2020-03-28 22:28 ` bergner at gcc dot gnu.org
2020-03-28 23:09 ` bergner at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-03-28 22:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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 ?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-03-28 22:28 ` bergner at gcc dot gnu.org
@ 2020-03-28 23:09 ` bergner at gcc dot gnu.org
2020-03-29 17:15 ` seurer at linux dot vnet.ibm.com
` (6 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-03-28 23:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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))
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-03-28 23:09 ` bergner at gcc dot gnu.org
@ 2020-03-29 17:15 ` seurer at linux dot vnet.ibm.com
2020-03-29 20:12 ` segher at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-03-29 17:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #12 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
confgures are identical.
Default compiler options are also identical, from -Q --help=target:
The following options are target specific:
-G<number> 0
-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 [disabled]
-mprioritize-restricted-insns= 0
-mprofile-kernel [disabled]
-mprototype [disabled]
-mquad-memory [enabled]
-mquad-memory-atomic [enabled]
-mreadonly-in-sdata [enabled]
-mrecip [disabled]
-mrecip-precision [enabled]
-mrecip=
-mregnames [disabled]
-mrelocatable [disabled]
-mrelocatable-lib [disabled]
-msave-toc-indirect [disabled]
-msched-costly-dep=
-msched-epilog [enabled]
-msched-groups [enabled]
-msched-prolog [enabled]
-msdata [disabled]
-msdata=[none,data,sysv,eabi]
-msecure-plt [disabled]
-mshlib [disabled]
-msim [disabled]
-msingle-pic-base [disabled]
-msoft-float [disabled]
-mspeculate-indirect-jumps [enabled]
-mstack-protector-guard-offset=
-mstack-protector-guard-reg=
-mstack-protector-guard= tls
-mstrict-align [disabled]
-mstring [disabled]
-mstring-compare-inline-limit= 64
-msum-in-toc [enabled]
-msvr4-struct-return [enabled]
-mtls-size=[16,32] 32
-mtoc [disabled]
-mtoc-fusion [disabled]
-mtraceback=[full,part,no] [default]
-mtune= [default]
-muclibc [disabled]
-munroll-only-small-loops [disabled]
-mupdate [enabled]
-mveclibabi=
-mvrsave [disabled]
-mvrsave=no -mvrsave
-mvrsave=yes -mvrsave
-mvsx [enabled]
-mvsx-align-128 [disabled]
-mvsx-timode [ignored]
-mwarn-altivec-long [enabled]
-mxl-compat [disabled]
-myellowknife [disabled]
Valid arguments to -malign-:
natural power
Known code models (for use with the -mcmodel= option):
large medium small
Known CPUs (for use with the -mcpu= and -mtune= options):
401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604
604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell
e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e future native
power3 power4 power5 power5+ power6 power6x power7 power8 power9 powerpc
powerpc64 powerpc64le rs64 titan
Valid arguments to -mstack-protector-guard=:
global tls
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-03-29 17:15 ` seurer at linux dot vnet.ibm.com
@ 2020-03-29 20:12 ` segher at gcc dot gnu.org
2020-04-01 15:00 ` seurer at linux dot vnet.ibm.com
` (4 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-03-29 20:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
If both compilers default to ibmlongdouble, both should use TFmode, no?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-03-29 20:12 ` segher at gcc dot gnu.org
@ 2020-04-01 15:00 ` seurer at linux dot vnet.ibm.com
2020-04-09 17:17 ` seurer at linux dot vnet.ibm.com
` (3 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-04-01 15:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #14 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
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...
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-04-01 15:00 ` seurer at linux dot vnet.ibm.com
@ 2020-04-09 17:17 ` seurer at linux dot vnet.ibm.com
2020-04-14 11:38 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-04-09 17:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #15 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-04-09 17:17 ` seurer at linux dot vnet.ibm.com
@ 2020-04-14 11:38 ` marxin at gcc dot gnu.org
2020-04-14 13:35 ` seurer at linux dot vnet.ibm.com
2020-04-14 13:38 ` marxin at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-14 11:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-04-14 11:38 ` marxin at gcc dot gnu.org
@ 2020-04-14 13:35 ` seurer at linux dot vnet.ibm.com
2020-04-14 13:38 ` marxin at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-04-14 13:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #17 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
Is there some earlier report to which this is a follow-on? The first comment
here sort of implies that.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/87163] ICE in extract_insn, at recog.c:2305
[not found] <bug-87163-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-04-14 13:35 ` seurer at linux dot vnet.ibm.com
@ 2020-04-14 13:38 ` marxin at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-14 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #18 from Martin Liška <marxin at gcc dot gnu.org> ---
Maybe PR86684?
^ permalink raw reply [flat|nested] 11+ messages in thread