[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Richard Biener  ---
Fixed since reverted.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #28 from Hongtao.liu  ---
(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).

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #27 from Segher Boessenkool  ---
(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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #26 from Segher Boessenkool  ---
(In reply to rguent...@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 :-)

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #25 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:57b7c432cce893e1ba60d9b94a9606df6b419379

commit r12-3457-g57b7c432cce893e1ba60d9b94a9606df6b419379
Author: liuhongt 
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

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #24 from 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  ---
> (In reply to rguent...@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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #23 from Segher Boessenkool  ---
(In reply to rguent...@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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #22 from Hongtao.liu  ---
(In reply to rguent...@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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #21 from 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).

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #20 from Segher Boessenkool  ---
(In reply to rguent...@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).

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[seurer at gcc dot gnu.org via 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

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #18 from 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  ---
> (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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #17 from Segher Boessenkool  ---
(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).

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

Martin Liška  changed:

   What|Removed |Added

 Target|ppc64-linux-gnu |ppc64-linux-gnu,
   ||aarch64-linux-gnu

--- Comment #16 from Martin Liška  ---
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 *));
}

$ ./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  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)

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #15 from Hongtao.liu  ---
(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:
> 
> 

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))"

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #14 from Segher Boessenkool  ---
(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:

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #13 from Jonathan Wakely  ---
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 [  ])
(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  for instructions.
compiler exited with status 1

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #12 from Hongtao.liu  ---
(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 [0xfff0])) [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  ] [117])
> (mem/c:SF (plus:DI (reg/f:DI 1 1)
> (const_int -16 [0xfff0])) [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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #11 from Hongtao.liu  ---
(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)

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #10 from Hongtao.liu  ---
(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 [0xfff0])) [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  ] [117])
(mem/c:SF (plus:DI (reg/f:DI 1 1)
(const_int -16 [0xfff0])) [4 %sfp+48 S4 A32]))
"/export/users2/liuhongt/tools-build/build_intel-innersource_ppc_debug/test.c":7:13
567 {movsf_hardfloat}

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #9 from Hongtao.liu  ---

> 
> (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))

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #8 from Hongtao.liu  ---
(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.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #7 from Hongtao.liu  ---
(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);
}

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #6 from Hongtao.liu  ---
Reproduced with a simple testcase


float
foo (long a)
{
  union{long a;
float b[2];}c;
  c.a = a;
  return c.b[1];
}

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

--- Comment #5 from Andrew Pinski  ---
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);
}

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154

Martin Liška  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  ---
Yes, it started with r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d.