public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769
@ 2021-09-01 7:06 marxin at gcc dot gnu.org
2021-09-01 7:06 ` [Bug target/102154] " marxin at gcc dot gnu.org
` (29 more replies)
0 siblings, 30 replies; 31+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-09-01 7:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Bug ID: 102154
Summary: [12 Regression] ICE in extract_insn, at recog.c:2769
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64-linux-gnu
Must be a recent regression:
$ ppc64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-2.c
-mpower9-misc -fno-inline -O2 -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-2.c:
In function ‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-2.c:54:1:
error: unrecognizable insn:
54 | }
| ^
(insn 24 23 25 4 (set (reg:SF 137)
(subreg:SF (reg:DI 117 [ _1 ]) 4))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-2.c":41:21
-1
(nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-2.c:54:1:
internal compiler error: in extract_insn, at recog.c:2769
0x5e832d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:108
0x5e8349 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:116
0x5e7766 extract_insn(rtx_insn*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/recog.c:2769
0x87cd1f instantiate_virtual_regs_in_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:1611
0x87cd1f instantiate_virtual_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:1985
0x87cd1f execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
@ 2021-09-01 7:06 ` marxin at gcc dot gnu.org
2021-09-01 7:08 ` pinskia at gcc dot gnu.org
` (28 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-09-01 7:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-09-01
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.0
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
2021-09-01 7:06 ` [Bug target/102154] " marxin at gcc dot gnu.org
@ 2021-09-01 7:08 ` pinskia at gcc dot gnu.org
2021-09-01 7:10 ` marxin at gcc dot gnu.org
` (27 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-01 7:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Was this pre or post r12-3276/r12-3277?
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
2021-09-01 7:06 ` [Bug target/102154] " marxin at gcc dot gnu.org
2021-09-01 7:08 ` pinskia at gcc dot gnu.org
@ 2021-09-01 7:10 ` marxin at gcc dot gnu.org
2021-09-01 7:11 ` crazylht at gmail dot com
` (26 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-09-01 7:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Happens with the current master
(r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d).
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2021-09-01 7:10 ` marxin at gcc dot gnu.org
@ 2021-09-01 7:11 ` crazylht at gmail dot com
2021-09-01 7:17 ` [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d marxin at gcc dot gnu.org
` (25 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 7:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Hongtao.liu <crazylht at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |crazylht at gmail dot com
--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
Very likely related to r12-3277.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2021-09-01 7:11 ` crazylht at gmail dot com
@ 2021-09-01 7:17 ` marxin at gcc dot gnu.org
2021-09-01 7:23 ` pinskia at gcc dot gnu.org
` (24 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-09-01 7:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[12 Regression] ICE in |[12 Regression] ICE in
|extract_insn, at |extract_insn, at
|recog.c:2769 |recog.c:2769 since
| |r12-3277-gd2874d905647a1d14
| |6dafa60199d440e837adc4d
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Yes, it started with r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2021-09-01 7:17 ` [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d marxin at gcc dot gnu.org
@ 2021-09-01 7:23 ` pinskia at gcc dot gnu.org
2021-09-01 8:00 ` crazylht at gmail dot com
` (23 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-01 7:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It might be this code:
/* Force the values into word_mode registers. */
for (i = 0; i < n_elts; i++)
{
rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
machine_mode tmode = TARGET_POWERPC64 ? DImode : SImode;
op[i] = simplify_gen_subreg (tmode, tmp, inner_mode, 0);
}
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2021-09-01 7:23 ` pinskia at gcc dot gnu.org
@ 2021-09-01 8:00 ` crazylht at gmail dot com
2021-09-01 8:17 ` crazylht at gmail dot com
` (22 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #6 from Hongtao.liu <crazylht at gmail dot com> ---
Reproduced with a simple testcase
float
foo (long a)
{
union{long a;
float b[2];}c;
c.a = a;
return c.b[1];
}
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2021-09-01 8:00 ` crazylht at gmail dot com
@ 2021-09-01 8:17 ` crazylht at gmail dot com
2021-09-01 8:35 ` crazylht at gmail dot com
` (21 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #6)
> Reproduced with a simple testcase
>
>
> float
> foo (long a)
> {
> union{long a;
> float b[2];}c;
> c.a = a;
> return c.b[1];
> }
(subreg:SF (reg:DI) 4) is genrated by extract_bit_field_as_subreg, x86 doesn't
have this error because if failed condition lowpart_bit_field_p while ppc64
passed.
the difference here is x86 is not BYTES_BIG_ENDIAN but ppc64.
static bool
lowpart_bit_field_p (poly_uint64 bitnum, poly_uint64 bitsize,
machine_mode struct_mode)
{
poly_uint64 regsize = REGMODE_NATURAL_SIZE (struct_mode);
if (BYTES_BIG_ENDIAN)
return (multiple_p (bitnum, BITS_PER_UNIT)
&& (known_eq (bitnum + bitsize, GET_MODE_BITSIZE (struct_mode))
|| multiple_p (bitnum + bitsize,
regsize * BITS_PER_UNIT)));
else
return multiple_p (bitnum, regsize * BITS_PER_UNIT);
}
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2021-09-01 8:17 ` crazylht at gmail dot com
@ 2021-09-01 8:35 ` crazylht at gmail dot com
2021-09-01 8:42 ` crazylht at gmail dot com
` (20 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #7)
> (In reply to Hongtao.liu from comment #6)
> > Reproduced with a simple testcase
> >
> >
> > float
> > foo (long a)
> > {
> > union{long a;
> > float b[2];}c;
> > c.a = a;
> > return c.b[1];
> > }
>
> (subreg:SF (reg:DI) 4) is genrated by extract_bit_field_as_subreg, x86
> doesn't have this error because if failed condition lowpart_bit_field_p
> while ppc64 passed.
>
> the difference here is x86 is not BYTES_BIG_ENDIAN but ppc64.
>
> static bool
> lowpart_bit_field_p (poly_uint64 bitnum, poly_uint64 bitsize,
> machine_mode struct_mode)
> {
> poly_uint64 regsize = REGMODE_NATURAL_SIZE (struct_mode);
> if (BYTES_BIG_ENDIAN)
> return (multiple_p (bitnum, BITS_PER_UNIT)
> && (known_eq (bitnum + bitsize, GET_MODE_BITSIZE (struct_mode))
> || multiple_p (bitnum + bitsize,
> regsize * BITS_PER_UNIT)));
> else
> return multiple_p (bitnum, regsize * BITS_PER_UNIT);
> }
(define_insn "movsf_hardfloat"
[(set (match_operand:SF 0 "nonimmediate_operand"
"=!r, f, v, wa, m, wY,
Z, m, wa, !r, f, wa,
!r, *c*l, !r, *h")
(match_operand:SF 1 "input_operand"
"m, m, wY, Z, f, v,
wa, r, j, j, f, wa,
r, r, *h, 0"))]
"(register_operand (operands[0], SFmode)
|| register_operand (operands[1], SFmode))
&& TARGET_HARD_FLOAT
&& (TARGET_ALLOW_SF_SUBREG
|| valid_sf_si_move (operands[0], operands[1], SFmode))"
Oh, The pattern disllow sf subreg.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2021-09-01 8:35 ` crazylht at gmail dot com
@ 2021-09-01 8:42 ` crazylht at gmail dot com
2021-09-01 8:50 ` crazylht at gmail dot com
` (19 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
>
> (define_insn "movsf_hardfloat"
> [(set (match_operand:SF 0 "nonimmediate_operand"
> "=!r, f, v, wa, m, wY,
> Z, m, wa, !r, f, wa,
> !r, *c*l, !r, *h")
> (match_operand:SF 1 "input_operand"
> "m, m, wY, Z, f, v,
> wa, r, j, j, f, wa,
> r, r, *h, 0"))]
> "(register_operand (operands[0], SFmode)
> || register_operand (operands[1], SFmode))
> && TARGET_HARD_FLOAT
> && (TARGET_ALLOW_SF_SUBREG
> || valid_sf_si_move (operands[0], operands[1], SFmode))"
>
> Oh, The pattern disllow sf subreg.
Here TARGET_ALLOW_SF_SUBREG || valid_sf_si_move (operands[0], operands[1],
SFmode) is false, others are true which means input_operand accept (subreg:SF
(reg:DI 4))
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2021-09-01 8:42 ` crazylht at gmail dot com
@ 2021-09-01 8:50 ` crazylht at gmail dot com
2021-09-01 8:52 ` crazylht at gmail dot com
` (18 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #9)
> >
> > (define_insn "movsf_hardfloat"
> > [(set (match_operand:SF 0 "nonimmediate_operand"
> > "=!r, f, v, wa, m, wY,
> > Z, m, wa, !r, f, wa,
> > !r, *c*l, !r, *h")
> > (match_operand:SF 1 "input_operand"
> > "m, m, wY, Z, f, v,
> > wa, r, j, j, f, wa,
> > r, r, *h, 0"))]
> > "(register_operand (operands[0], SFmode)
> > || register_operand (operands[1], SFmode))
> > && TARGET_HARD_FLOAT
> > && (TARGET_ALLOW_SF_SUBREG
> > || valid_sf_si_move (operands[0], operands[1], SFmode))"
> >
> > Oh, The pattern disllow sf subreg.
>
> Here TARGET_ALLOW_SF_SUBREG || valid_sf_si_move (operands[0], operands[1],
> SFmode) is false, others are true which means input_operand accept
> (subreg:SF (reg:DI 4))
And w/ -mpower10 (subreg:SF (reg:DI 4) 0) can be handled by reload to
(insn 6 3 16 2 (set (mem/c:SF (plus:DI (reg/f:DI 1 1)
(const_int -16 [0xfffffffffffffff0])) [4 %sfp+48 S4 A32])
(reg:SF 3 3 [orig:120+4 ] [120]))
"/export/users2/liuhongt/tools-build/build_intel-innersource_ppc_debug/test.c":7:13
567 {movsf_hardfloat}
(nil))
(insn 16 6 11 2 (set (reg:SF 33 1 [orig:117 <retval> ] [117])
(mem/c:SF (plus:DI (reg/f:DI 1 1)
(const_int -16 [0xfffffffffffffff0])) [4 %sfp+48 S4 A32]))
"/export/users2/liuhongt/tools-build/build_intel-innersource_ppc_debug/test.c":7:13
567 {movsf_hardfloat}
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2021-09-01 8:50 ` crazylht at gmail dot com
@ 2021-09-01 8:52 ` crazylht at gmail dot com
2021-09-01 8:58 ` crazylht at gmail dot com
` (17 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #11 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > >
> > > (define_insn "movsf_hardfloat"
> > > [(set (match_operand:SF 0 "nonimmediate_operand"
> > > "=!r, f, v, wa, m, wY,
> > > Z, m, wa, !r, f, wa,
> > > !r, *c*l, !r, *h")
> > > (match_operand:SF 1 "input_operand"
> > > "m, m, wY, Z, f, v,
> > > wa, r, j, j, f, wa,
> > > r, r, *h, 0"))]
> > > "(register_operand (operands[0], SFmode)
> > > || register_operand (operands[1], SFmode))
> > > && TARGET_HARD_FLOAT
> > > && (TARGET_ALLOW_SF_SUBREG
> > > || valid_sf_si_move (operands[0], operands[1], SFmode))"
> > >
> > > Oh, The pattern disllow sf subreg.
> >
> > Here TARGET_ALLOW_SF_SUBREG || valid_sf_si_move (operands[0], operands[1],
> > SFmode) is false, others are true which means input_operand accept
> > (subreg:SF (reg:DI 4))
>
> And w/ -mpower10 (subreg:SF (reg:DI 4) 0) can be handled by reload to
>
typo should be (subreg:SF (reg:DI) 4)
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2021-09-01 8:52 ` crazylht at gmail dot com
@ 2021-09-01 8:58 ` crazylht at gmail dot com
2021-09-02 17:16 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-01 8:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #12 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > >
> > > (define_insn "movsf_hardfloat"
> > > [(set (match_operand:SF 0 "nonimmediate_operand"
> > > "=!r, f, v, wa, m, wY,
> > > Z, m, wa, !r, f, wa,
> > > !r, *c*l, !r, *h")
> > > (match_operand:SF 1 "input_operand"
> > > "m, m, wY, Z, f, v,
> > > wa, r, j, j, f, wa,
> > > r, r, *h, 0"))]
> > > "(register_operand (operands[0], SFmode)
> > > || register_operand (operands[1], SFmode))
> > > && TARGET_HARD_FLOAT
> > > && (TARGET_ALLOW_SF_SUBREG
> > > || valid_sf_si_move (operands[0], operands[1], SFmode))"
> > >
> > > Oh, The pattern disllow sf subreg.
> >
> > Here TARGET_ALLOW_SF_SUBREG || valid_sf_si_move (operands[0], operands[1],
> > SFmode) is false, others are true which means input_operand accept
> > (subreg:SF (reg:DI 4))
>
> And w/ -mpower10 (subreg:SF (reg:DI 4) 0) can be handled by reload to
>
> (insn 6 3 16 2 (set (mem/c:SF (plus:DI (reg/f:DI 1 1)
> (const_int -16 [0xfffffffffffffff0])) [4 %sfp+48 S4 A32])
> (reg:SF 3 3 [orig:120+4 ] [120]))
> "/export/users2/liuhongt/tools-build/build_intel-innersource_ppc_debug/test.
> c":7:13 567 {movsf_hardfloat}
> (nil))
> (insn 16 6 11 2 (set (reg:SF 33 1 [orig:117 <retval> ] [117])
> (mem/c:SF (plus:DI (reg/f:DI 1 1)
> (const_int -16 [0xfffffffffffffff0])) [4 %sfp+48 S4 A32]))
> "/export/users2/liuhongt/tools-build/build_intel-innersource_ppc_debug/test.
> c":7:13 567 {movsf_hardfloat}
And it seems TARGET_ALLOW_SF_SUBREG is not needed here, there's no 64-bit move
instruction generated.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2021-09-01 8:58 ` crazylht at gmail dot com
@ 2021-09-02 17:16 ` redi at gcc dot gnu.org
2021-09-02 18:10 ` segher at gcc dot gnu.org
` (15 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: redi at gcc dot gnu.org @ 2021-09-02 17:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Is this also the cause of several libstdc++ FAILs on ppc64le?
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:2936:
error: unrecognizable insn:
(insn 11 10 12 2 (set (reg:SF 118 [ <retval> ])
(subreg:SF (reg:DI 122) 0))
"/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h":2936:16
-1
(nil))
during RTL pass: vregs
/home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:2936:
internal compiler error: in extract_insn, at recog.c:2769
0x10221bb7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jwakely/src/gcc/gcc/rtl-error.c:108
0x10221c0f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/jwakely/src/gcc/gcc/rtl-error.c:116
0x10de48af extract_insn(rtx_insn*)
/home/jwakely/src/gcc/gcc/recog.c:2769
0x10a3c82f instantiate_virtual_regs_in_insn
/home/jwakely/src/gcc/gcc/function.c:1611
0x10a3c82f instantiate_virtual_regs
/home/jwakely/src/gcc/gcc/function.c:1985
0x10a3c82f execute
/home/jwakely/src/gcc/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (13 preceding siblings ...)
2021-09-02 17:16 ` redi at gcc dot gnu.org
@ 2021-09-02 18:10 ` segher at gcc dot gnu.org
2021-09-03 7:58 ` crazylht at gmail dot com
` (14 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-02 18:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #14 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #13)
> Is this also the cause of several libstdc++ FAILs on ppc64le?
Yes.
I have asked for reversion of g:d2874d905647:
<https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578714.html>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (14 preceding siblings ...)
2021-09-02 18:10 ` segher at gcc dot gnu.org
@ 2021-09-03 7:58 ` crazylht at gmail dot com
2021-09-08 7:57 ` marxin at gcc dot gnu.org
` (13 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-03 7:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Jonathan Wakely from comment #13)
> > Is this also the cause of several libstdc++ FAILs on ppc64le?
>
>
> Yes.
>
> I have asked for reversion of g:d2874d905647:
>
> <https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578714.html>
as discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
specific float-int subreg seems weird.
And when i look the pattern, it also seems to be strange to disallow subreg in
operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in
TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing.
define_insn "movsf_hardfloat"
[(set (match_operand:SF 0 "nonimmediate_operand"
"=!r, f, v, wa, m, wY,
Z, m, wa, !r, f, wa,
!r, *c*l, !r, *h")
(match_operand:SF 1 "input_operand"
"m, m, wY, Z, f, v,
wa, r, j, j, f, wa,
r, r, *h, 0"))]
"(register_operand (operands[0], SFmode)
|| register_operand (operands[1], SFmode))
&& TARGET_HARD_FLOAT
&& (TARGET_ALLOW_SF_SUBREG
|| valid_sf_si_move (operands[0], operands[1], SFmode))"
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (15 preceding siblings ...)
2021-09-03 7:58 ` crazylht at gmail dot com
@ 2021-09-08 7:57 ` marxin at gcc dot gnu.org
2021-09-08 17:51 ` segher at gcc dot gnu.org
` (12 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-09-08 7:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|ppc64-linux-gnu |ppc64-linux-gnu,
| |aarch64-linux-gnu
--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
One more problem I noticed that started with this revision:
$ cat pr48641.c
#define MODFL __builtin_modfl
void foo() {
long iptrll;
MODFL(0.5l, (long double *)&iptrll);
}
$ ./xgcc -B. pr48641.c -frounding-math -Og -fno-tree-fre
pr48641.c: In function ‘foo’:
pr48641.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 5 2 0 2 (set (subreg:TF (reg/v:DI 92 [ iptrll ]) 0)
(const_double:TF 0.0 [0x0.0p+0])) "pr48641.c":4:3 -1
(nil))
during RTL pass: vregs
pr48641.c:5:1: internal compiler error: in extract_insn, at recog.c:2769
0x139d818 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc2/gcc/rtl-error.c:108
0x139d859 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc2/gcc/rtl-error.c:116
0x134c026 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc2/gcc/recog.c:2769
0xf8ab2c instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc2/gcc/function.c:1611
0xf8c141 instantiate_virtual_regs
/home/marxin/Programming/gcc2/gcc/function.c:1985
0xf8c212 execute
/home/marxin/Programming/gcc2/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: aarch64-linux-gnu
Configured with: /home/marxin/Programming/gcc2/configure --enable-languages=c
--prefix=/home/marxin/bin/gcc --disable-multilib --disable-libsanitizer
--disable-bootstrap --target=aarch64-linux-gnu : (reconfigured)
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210901 (experimental) (GCC)
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (16 preceding siblings ...)
2021-09-08 7:57 ` marxin at gcc dot gnu.org
@ 2021-09-08 17:51 ` segher at gcc dot gnu.org
2021-09-09 7:15 ` rguenther at suse dot de
` (11 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-08 17:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #15)
> as discussed in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
> specific float-int subreg seems weird.
Indiscriminately allowing all of them is a bad idea. No machine (that has
more than just integer hardware) can actually use those, resulting in ICEs
(like here) or inefficient code generated by reload, or a mix, or worse.
> And when i look the pattern, it also seems to be strange to disallow subreg
> in operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in
> TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing.
No. We usually have this in the predicates. But there simply is no even
remotely efficient way to do such moves, so we should not pretend there is.
It would be nicer to disallow such subregs elsewhere, sure.
(And rs6000_can_change_mode_class already disallows this move fwiw).
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (17 preceding siblings ...)
2021-09-08 17:51 ` segher at gcc dot gnu.org
@ 2021-09-09 7:15 ` rguenther at suse dot de
2021-09-09 19:03 ` seurer at gcc dot gnu.org
` (10 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2021-09-09 7:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 8 Sep 2021, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> (In reply to Hongtao.liu from comment #15)
> > as discussed in
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
> > specific float-int subreg seems weird.
>
> Indiscriminately allowing all of them is a bad idea. No machine (that has
> more than just integer hardware) can actually use those, resulting in ICEs
> (like here) or inefficient code generated by reload, or a mix, or worse.
>
> > And when i look the pattern, it also seems to be strange to disallow subreg
> > in operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in
> > TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing.
>
> No. We usually have this in the predicates. But there simply is no even
> remotely efficient way to do such moves, so we should not pretend there is.
So I wonder if it makes sense to allow lowpart subregs of any mode when
the inner mode is integer. There's already
/* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though
store_bit_field
is the culprit here, and not the backends. */
else if (known_ge (osize, regsize) && known_ge (isize, osize))
;
where regsize is REGMODE_NATURAL_SIZE (imode) but with a HFmode
subreg of DImode the known_ge (osize, regsize) doesn't apply
(I wonder what that condition is about - it looks rather arbitrary).
The above allowance also doesn't restrict the subreg offset in any way.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (18 preceding siblings ...)
2021-09-09 7:15 ` rguenther at suse dot de
@ 2021-09-09 19:03 ` seurer at gcc dot gnu.org
2021-09-09 22:47 ` segher at gcc dot gnu.org
` (9 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-09-09 19:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #19 from seurer at gcc dot gnu.org ---
This also prevents gcc from being built if it includes go on powerpc LE:
libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-O2 -g -I . -c -fgo-pkgpath=strconv
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
.libs/strconv.o
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
'strconv.parseFloatPrefix':
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
unrecognizable insn:
704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
| ^
(insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
(subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
"/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go":601:15 -1
(nil))
during RTL pass: vregs
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: internal compiler
error: in extract_insn, at recog.c:2769
0x102b46d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/seurer/gcc/git/gcc-test/gcc/rtl-error.c:108
0x102b4723 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/seurer/gcc/git/gcc-test/gcc/rtl-error.c:116
0x10afebe7 extract_insn(rtx_insn*)
/home/seurer/gcc/git/gcc-test/gcc/recog.c:2769
0x1070e8f7 instantiate_virtual_regs_in_insn
/home/seurer/gcc/git/gcc-test/gcc/function.c:1611
0x1070e8f7 instantiate_virtual_regs
/home/seurer/gcc/git/gcc-test/gcc/function.c:1985
0x1070e8f7 execute
/home/seurer/gcc/git/gcc-test/gcc/function.c:2034
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (19 preceding siblings ...)
2021-09-09 19:03 ` seurer at gcc dot gnu.org
@ 2021-09-09 22:47 ` segher at gcc dot gnu.org
2021-09-10 7:21 ` rguenther at suse dot de
` (8 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-09 22:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #18)
> So I wonder if it makes sense to allow lowpart subregs of any mode when
> the inner mode is integer.
We really really really should make a separate bit_cast rtx code.
Other than that I agree, yes. But I do fear there will be quite a bit of
fallout from that still, albeit less than with the current patch.
> There's already
>
> /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though
> store_bit_field
> is the culprit here, and not the backends. */
> else if (known_ge (osize, regsize) && known_ge (isize, osize))
> ;
>
> where regsize is REGMODE_NATURAL_SIZE (imode) but with a HFmode
> subreg of DImode the known_ge (osize, regsize) doesn't apply
> (I wonder what that condition is about - it looks rather arbitrary).
Very long ago it made sense to consider quantities greater than "regsize"
to take up more than one register. Nowadays we have normal registers
bigger than "regsize" (which actually is the size of the mode used).
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (20 preceding siblings ...)
2021-09-09 22:47 ` segher at gcc dot gnu.org
@ 2021-09-10 7:21 ` rguenther at suse dot de
2021-09-10 7:53 ` crazylht at gmail dot com
` (7 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2021-09-10 7:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 9 Sep 2021, seurer at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #19 from seurer at gcc dot gnu.org ---
> This also prevents gcc from being built if it includes go on powerpc LE:
>
> libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
> -B/home/seurer/gcc/git/build/gcc-test/./gcc/
> -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
> -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
> -isystem
> /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
> -isystem
> /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
> -O2 -g -I . -c -fgo-pkgpath=strconv
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
> .libs/strconv.o
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
> 'strconv.parseFloatPrefix':
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> unrecognizable insn:
> 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> | ^
> (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
Btw, I think this is a subreg that would be reasonable to handle.
It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
..) 0).
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (21 preceding siblings ...)
2021-09-10 7:21 ` rguenther at suse dot de
@ 2021-09-10 7:53 ` crazylht at gmail dot com
2021-09-10 9:12 ` segher at gcc dot gnu.org
` (6 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-10 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #22 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to rguenther@suse.de from comment #21)
> On Thu, 9 Sep 2021, seurer at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
> >
> > --- Comment #19 from seurer at gcc dot gnu.org ---
> > This also prevents gcc from being built if it includes go on powerpc LE:
> >
> > libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
> > -B/home/seurer/gcc/git/build/gcc-test/./gcc/
> > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
> > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
> > -isystem
> > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
> > -isystem
> > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
> > -O2 -g -I . -c -fgo-pkgpath=strconv
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
> > .libs/strconv.o
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
> > 'strconv.parseFloatPrefix':
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > | ^
> > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
>
> Btw, I think this is a subreg that would be reasonable to handle.
> It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> ..) 0).
Yes, LRA/reload can handle it correctly, like i tried in #c10.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (22 preceding siblings ...)
2021-09-10 7:53 ` crazylht at gmail dot com
@ 2021-09-10 9:12 ` segher at gcc dot gnu.org
2021-09-10 9:49 ` rguenther at suse dot de
` (5 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-10 9:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #21)
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > | ^
> > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
>
> Btw, I think this is a subreg that would be reasonable to handle.
> It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> ..) 0).
And it is more than reasonable for backends to *not* have to handle such
constructs. Most targets have no use for such surprising things.
The expander should never create such code in the first place, it is premature
optimisation! At expand time this should be separate statements, first taking
a SI out of a DI, and then converting it to an SF.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (23 preceding siblings ...)
2021-09-10 9:12 ` segher at gcc dot gnu.org
@ 2021-09-10 9:49 ` rguenther at suse dot de
2021-09-10 21:55 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2021-09-10 9:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 10 Sep 2021, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #21)
> > > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > > unrecognizable insn:
> > > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > > | ^
> > > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
> >
> > Btw, I think this is a subreg that would be reasonable to handle.
> > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> > ..) 0).
>
> And it is more than reasonable for backends to *not* have to handle such
> constructs. Most targets have no use for such surprising things.
>
> The expander should never create such code in the first place, it is premature
> optimisation! At expand time this should be separate statements, first taking
> a SI out of a DI, and then converting it to an SF.
Fair enough - but extract_bit_field doesn't do this and forcing it to do
it regresses things (that was my first preferential treatment...).
I realize that the situation around subregs is fragile and there's
unlikely going to be a solution that doesn't need fixes in other targets.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (24 preceding siblings ...)
2021-09-10 9:49 ` rguenther at suse dot de
@ 2021-09-10 21:55 ` cvs-commit at gcc dot gnu.org
2021-09-10 22:29 ` segher at gcc dot gnu.org
` (3 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-09-10 21:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:
https://gcc.gnu.org/g:57b7c432cce893e1ba60d9b94a9606df6b419379
commit r12-3457-g57b7c432cce893e1ba60d9b94a9606df6b419379
Author: liuhongt <hongtao.liu@intel.com>
Date: Fri Sep 10 20:02:25 2021 +0800
Revert "Get rid of all float-int special cases in validate_subreg."
This reverts commit d2874d905647a1d146dafa60199d440e837adc4d.
PR target/102254
PR target/102154
PR target/102211
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (25 preceding siblings ...)
2021-09-10 21:55 ` cvs-commit at gcc dot gnu.org
@ 2021-09-10 22:29 ` segher at gcc dot gnu.org
2021-09-10 22:33 ` segher at gcc dot gnu.org
` (2 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-10 22:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #24)
> > The expander should never create such code in the first place, it is premature
> > optimisation! At expand time this should be separate statements, first taking
> > a SI out of a DI, and then converting it to an SF.
>
> Fair enough - but extract_bit_field doesn't do this and forcing it to do
> it regresses things (that was my first preferential treatment...).
Yes, it needs to be fixed one step at a time. Since subreg does six or seven
different things anything with it is a tangled mess, and we cannot move things
forward unless we untangle things. That is also how we can do this without
regressing things left and right: first we should *only* open things up, make
things more manageable, easier to change.
This will take time, I am not under the illusion that it can be finished in
time for GCC 12. But if we do not start now, it will not be done in GCC 13
either.
> I realize that the situation around subregs is fragile and there's
> unlikely going to be a solution that doesn't need fixes in other targets.
Right. But if we tackle one thing at a time, and make things *simpler*, and
add testcases -- then it should not be all that hard in the end. Painful,
yes, I don't think we can avoid that :-)
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (26 preceding siblings ...)
2021-09-10 22:29 ` segher at gcc dot gnu.org
@ 2021-09-10 22:33 ` segher at gcc dot gnu.org
2021-09-11 15:09 ` crazylht at gmail dot com
2022-01-17 13:34 ` rguenth at gcc dot gnu.org
29 siblings, 0 replies; 31+ messages in thread
From: segher at gcc dot gnu.org @ 2021-09-10 22:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #27 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #22)
> > Btw, I think this is a subreg that would be reasonable to handle.
> > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> > ..) 0).
>
> Yes, LRA/reload can handle it correctly, like i tried in #c10.
It is fundamentally wrong to rely on reloading for non-exceptional code.
If reloading creates good code you are very lucky. And the whole point of
doing any of this with subregs is to get good code.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (27 preceding siblings ...)
2021-09-10 22:33 ` segher at gcc dot gnu.org
@ 2021-09-11 15:09 ` crazylht at gmail dot com
2022-01-17 13:34 ` rguenth at gcc dot gnu.org
29 siblings, 0 replies; 31+ messages in thread
From: crazylht at gmail dot com @ 2021-09-11 15:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #28 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Segher Boessenkool from comment #27)
> (In reply to Hongtao.liu from comment #22)
> > > Btw, I think this is a subreg that would be reasonable to handle.
> > > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> > > ..) 0).
> >
> > Yes, LRA/reload can handle it correctly, like i tried in #c10.
>
> It is fundamentally wrong to rely on reloading for non-exceptional code.
> If reloading creates good code you are very lucky. And the whole point of
> doing any of this with subregs is to get good code.
I don't have direct evidence to proof LRA/reload is functionally ok to handle
subreg, but x86 have a very heavy use of subreg, also there're comments in
general_operand saying below which makes me believe LRA/reload can handle
subreg right.
if (SCALAR_FLOAT_MODE_P (GET_MODE (op))
/* LRA can use subreg to store a floating point value in an
integer mode. Although the floating point and the
integer modes need the same number of hard registers, the
size of floating point mode can be less than the integer
mode. */
&& ! lra_in_progress
&& paradoxical_subreg_p (op))
return false;
Back to #c10, because I don't know much about the power architecture, the
solution in #c10 that relies on reload to solve this (subreg:SF (reg:DI) 0) is
wrong.
The real problem for rs6000 is SFmode is represented as DFmode in the vector
and floating point registers, and this can't be handled by reload.
validate_subreg disallow (subreg:SF (reg:DI) 0) just so happens that you have
one less special subreg to deal with. there's already
rs6000_emit_move_si_sf_subreg to hanlde (subreg:SF (reg:SI) 0).
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
` (28 preceding siblings ...)
2021-09-11 15:09 ` crazylht at gmail dot com
@ 2022-01-17 13:34 ` rguenth at gcc dot gnu.org
29 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-17 13:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed since reverted.
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2022-01-17 13:34 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-01 7:06 [Bug target/102154] New: [12 Regression] ICE in extract_insn, at recog.c:2769 marxin at gcc dot gnu.org
2021-09-01 7:06 ` [Bug target/102154] " marxin at gcc dot gnu.org
2021-09-01 7:08 ` pinskia at gcc dot gnu.org
2021-09-01 7:10 ` marxin at gcc dot gnu.org
2021-09-01 7:11 ` crazylht at gmail dot com
2021-09-01 7:17 ` [Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d marxin at gcc dot gnu.org
2021-09-01 7:23 ` pinskia at gcc dot gnu.org
2021-09-01 8:00 ` crazylht at gmail dot com
2021-09-01 8:17 ` crazylht at gmail dot com
2021-09-01 8:35 ` crazylht at gmail dot com
2021-09-01 8:42 ` crazylht at gmail dot com
2021-09-01 8:50 ` crazylht at gmail dot com
2021-09-01 8:52 ` crazylht at gmail dot com
2021-09-01 8:58 ` crazylht at gmail dot com
2021-09-02 17:16 ` redi at gcc dot gnu.org
2021-09-02 18:10 ` segher at gcc dot gnu.org
2021-09-03 7:58 ` crazylht at gmail dot com
2021-09-08 7:57 ` marxin at gcc dot gnu.org
2021-09-08 17:51 ` segher at gcc dot gnu.org
2021-09-09 7:15 ` rguenther at suse dot de
2021-09-09 19:03 ` seurer at gcc dot gnu.org
2021-09-09 22:47 ` segher at gcc dot gnu.org
2021-09-10 7:21 ` rguenther at suse dot de
2021-09-10 7:53 ` crazylht at gmail dot com
2021-09-10 9:12 ` segher at gcc dot gnu.org
2021-09-10 9:49 ` rguenther at suse dot de
2021-09-10 21:55 ` cvs-commit at gcc dot gnu.org
2021-09-10 22:29 ` segher at gcc dot gnu.org
2021-09-10 22:33 ` segher at gcc dot gnu.org
2021-09-11 15:09 ` crazylht at gmail dot com
2022-01-17 13:34 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).