[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 Andrew Pinski changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #6 from Andrew Pinski --- *** Bug 100840 has been marked as a duplicate of this bug. ***
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899
--- Comment #5 from Arseny Solokha ---
I believe practically all gcc branches, the current gcc-11.0.1-alpha20210314
snapshot (g:c2d7c39fcb8a3cb67600cdb6fde49ecb0e951589) included, demonstrate the
same issue on
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c w/ -O1
-ffinite-math-only:
% x86_64-unknown-linux-gnu-gcc-11.0.1 -O1 -ffinite-math-only -c
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c: In function
'main':
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c:11:3: error:
output constraint 0 must specify a single register
11 | asm("lxr\t%0,%1\n"
| ^~~
during RTL pass: stack
gcc/testsuite/gcc.target/s390/vector/long-double-asm-commutative.c:16:1:
internal compiler error: in replace_reg, at reg-stack.c:714
16 | }
| ^
0x6b654d replace_reg
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:714
0xd6e91b compare_for_stack_reg
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:1379
0xd6e91b subst_stack_regs_pat
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:2001
0xd6f212 subst_stack_regs
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:2444
0xd6f418 convert_regs_1
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3080
0xd6f418 convert_regs_2
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3214
0xd704c8 convert_regs
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3249
0xd704c8 reg_to_stack
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3374
0xd704c8 rest_of_handle_stack_regs
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3429
0xd704c8 execute
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210314/work/gcc-11-20210314/gcc/reg-stack.c:3461
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- None of the above test cases gives an ICE on x86_64-pc-linux-gnu, even when gcc-11 is configured with --enable-checking=yes.
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- I cannot reproduce this ICE on all active branches.
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
||com
--- Comment #2 from David ---
To confirm the ice and to provide more details:
double a;
fn1(){ asm("" : "=t"(a) : "0u"(0)); } // replace_reg at reg-stack.c:687
fn2(){ asm("" : "=t"(a) : "0u"(0.0)); } // No ICE
fn3(){ asm("" : "=t"(a) : "u"(0.0)); } // change_stack at reg-stack.c:2522
fn1 is the OP's code. Changing the input to a float (0.0 vs 0) resolves the
first ICE, but removing the "0" from the input constraint throws another.
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Even in 3.2 I see: /usr/src/gcc-3.2/obj/gcc/cc1 -quiet pr69899.c -m64 pr69899.c: In function `foo': pr69899.c:2: `asm' operand requires impossible reload pr69899.c:2: confused by earlier errors, bailing out /usr/src/gcc-3.2/obj/gcc/cc1 -quiet pr69899.c -m32 pr69899.c: In function `foo': pr69899.c:2: `asm' operand constraint incompatible with operand size /usr/src/gcc-4.4/obj/gcc/cc1 -quiet pr69899.c -m64 pr69899.c: In function ‘foo’: pr69899.c:2: error: ‘asm’ operand requires impossible reload pr69899.c:2: confused by earlier errors, bailing out /usr/src/gcc-4.4/obj/gcc/cc1 -quiet pr69899.c -m32 pr69899.c: In function ‘foo’: pr69899.c:2: error: ‘asm’ operand constraint incompatible with operand size pr69899.c:2: error: ‘asm’ operand has impossible constraints So at least for -m64 this is not a regression (well, to some extent a regression from error-recovery ICE to normal ice-on-invalid-code). For -m32, the behavior changed with r192719 aka when LRA has been added.
