[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Uroš Bizjak --- Fixed.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 Uroš Bizjak changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #12 from Uroš Bizjak --- *** Bug 82827 has been marked as a duplicate of this bug. ***
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #11 from dansan at gcc dot gnu.org --- Author: dansan Date: Sat Nov 4 22:38:43 2017 New Revision: 254412 URL: https://gcc.gnu.org/viewcvs?rev=254412=gcc=rev Log: PR target/82002 Part 2: Correct non-immediate offset/invalid INSN When we are realigning the stack pointer, making an ms_abi to sysv_abi call and allocating 2GiB or more on the stack we end up with an invalid INSN due to a non-immediate offset. This occurs both with and without -mcall-ms2sysv-xlogues. Additionally, the stack allocation with -mcall-ms2sysv-xlogues is ignoring (silently disabling) stack checking, stack clash checking and probing. This patch fixes these problems by: 1. No longer allocate stack space in ix86_emit_outlined_ms2sysv_save. 2. Rearrange where we emit SSE saves or stub call: a. Before frame allocation when offset from frame to save area is >= 2GiB. b. After frame allocation when frame is < 2GiB. (Stack allocations prior to the stub call can't be combined with those afterwards, so this is better when possible.) 3. Modify choose_baseaddr to take an optional scratch_regno argument and never return rtx that cannot be used as an immediate. gcc: config/i386/i386.c (choose_basereg): Use optional scratch register and add assertion. (x86_emit_outlined_ms2sysv_save): Use scratch register when needed, and don't allocate stack. (ix86_expand_prologue): Rearrange where SSE saves/stub call is emitted, correct wrong allocation with -mcall-ms2sysv-xlogues. (ix86_emit_outlined_ms2sysv_restore): Fix non-immediate offsets. gcc/testsuite: gcc.target/i386/pr82002-2a.c: Change from xfail to fail. gcc.target/i386/pr82002-2b.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr82002-2a.c trunk/gcc/testsuite/gcc.target/i386/pr82002-2b.c
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #10 from Jakub Jelinek --- pr82002-2a.c as well as pr82002-2b.c still ICE on the current trunk on x86_64-linux: /home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c: In function 'b': /home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c:14:1: error: unrecognizable insn: (insn/f 36 35 37 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp) (const_int 116 [0x2540be410])) [2 S16 A128]) (reg:V4SF 27 xmm6)) "/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c":9 -1 (expr_list:REG_DEAD (reg:V4SF 27 xmm6) (expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp) (const_int 116 [0x2540be410])) [2 S16 A128]) (reg:V4SF 27 xmm6)) (nil during RTL pass: cprop_hardreg
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #9 from dansan at gcc dot gnu.org --- Author: dansan Date: Tue Oct 31 21:48:55 2017 New Revision: 254284 URL: https://gcc.gnu.org/viewcvs?rev=254284=gcc=rev Log: PR target/82002 Part 1: Correct ICE caused by wrong calculation gcc: config/i386/i386.c (ix86_expand_epilogue): Correct stack calculation. gcc/testsuite: gcc.target/i386/pr82002-1.c: New test. gcc.target/i386/pr82002-2a.c: New xfail test. gcc.target/i386/pr82002-2b.c: New xfail test. Added: trunk/gcc/testsuite/gcc.target/i386/pr82002-1.c trunk/gcc/testsuite/gcc.target/i386/pr82002-2a.c trunk/gcc/testsuite/gcc.target/i386/pr82002-2b.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #8 from Uroš Bizjak --- *** Bug 82485 has been marked as a duplicate of this bug. ***
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #7 from Uroš Bizjak --- *** Bug 82712 has been marked as a duplicate of this bug. ***
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #6 from Daniel Santos --- Was about to submit a patch set for this that added this nifty mechanism to track a scratch register for pro/epilogue use and automatically (re)use it when you call choose_baseaddr. Then I realized that I could circumvent the whole thing by emitting the SSE saves or stub call in one of two places based upon the offset size with much less new complexity. Will be testing shortly.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #5 from Daniel Santos --- (In reply to Daniel Santos from comment #4) > The alternative that I can see is to modify choose_baseaddr so that it can > init and utilize an auxiliary register (like r11). I guess this would be called a "scratch" register.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #4 from Daniel Santos --- Created attachment 42147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42147=edit incomplete patch set with test (In reply to Jakub Jelinek from comment #3) > Of course there is none. Which is why e.g. pro_epilogue_adjust_stack has > code to handle the case when Pmode is not SImode and offset is not > x86_64_immediate_operand. So whatever generated this insn also needs to > test for sp + offset not being a valid address and load the offset into some > hard register first and use sp + that_reg. pro_and_epilogue pass is after > reload, so we can't wait for RA to handle it for us. Thanks for the help here Jakub. Being new to gcc (and obviously the x86 backend), I'm learning about issues that weren't "on my radar", so sorry for dragging you guys through some of this as well. This came about because I moved the stack realignment boundary from the start of the function's frame to after the GP reg saves so that we could use aligned MOVs for SSE regs. Prior to this, we just used the frame pointer with possibly unaligned MOVs and that offset was never very large. The bad operand is being generated when ix86_emit_save_sse_regs_using_mov calls choose_baseaddr. I wouldn't at all mind using the frame pointer with possibly unaligned MOVs for a case like this, but I'm not sure what the best solution is. This would mean that the realignment boundary ix86_frame::stack_realign_offset could represent two different locations, either after reg_save_offset or at stack_pointer_offset. This would require adding an alternative calculation to the if (stack_realign_fp) else block in ix86_compute_frame_layout (basically, readd the old way it was calculated), and -ms2sysv-xlogues might have to either be disabled or modified since it uses choose_baseaddr to init rax/rsi prior to calling the stub. The alternative that I can see is to modify choose_baseaddr so that it can init and utilize an auxiliary register (like r11). In this case, I'm thinking that it might make sense to do something global to track what regs are available rather than passing 'style' everywhere to know rather or not r11 is live and also track auxiliary register(s) such as this so we can init it once and then use it several times. I know we're approaching the end of stage1, so don't want to shake things up too much now. Please let me know what you think. I might post this to the list for opinions too. I'm attaching what I have of the fix for this -- it solves the problem that was posted, but it's still broken when we call a sysv function from an ms function. Thanks
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Daniel Santos from comment #2) > Another problem when we throw in an ms to sysv call: > /home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c: In > function 'b': > /home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c:12: > 1: error: unrecognizable insn: > (insn/f 36 35 37 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp) > (const_int 116 [0x2540be410])) [2 S16 A128]) > (reg:V4SF 27 xmm6)) > "/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c":7 > -1 > (expr_list:REG_DEAD (reg:V4SF 27 xmm6) > (expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 > sp) > (const_int 116 [0x2540be410])) [2 S16 A128]) > (reg:V4SF 27 xmm6)) > (nil > during RTL pass: cprop_hardreg > /home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c:12: > 1: internal compiler error: in extract_insn, at recog.c:2306 > 0x5c1958 _fatal_insn(char const*, rtx_def const*, char const*, int, char > const*) > /home/daniel/proj/sys/gcc/git/gcc/rtl-error.c:108 > 0x5c1974 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) > /home/daniel/proj/sys/gcc/git/gcc/rtl-error.c:116 > 0xba05a9 extract_insn(rtx_insn*) > /home/daniel/proj/sys/gcc/git/gcc/recog.c:2306 > 0xba15e8 extract_constrain_insn(rtx_insn*) > /home/daniel/proj/sys/gcc/git/gcc/recog.c:2206 > 0xbaaaf6 copyprop_hardreg_forward_1 > /home/daniel/proj/sys/gcc/git/gcc/regcprop.c:801 > 0xbab8a4 execute > /home/daniel/proj/sys/gcc/git/gcc/regcprop.c:1308 > > > I guess we don't have a 64-bit offset instruction for (v)movabs :) Of course there is none. Which is why e.g. pro_epilogue_adjust_stack has code to handle the case when Pmode is not SImode and offset is not x86_64_immediate_operand. So whatever generated this insn also needs to test for sp + offset not being a valid address and load the offset into some hard register first and use sp + that_reg. pro_and_epilogue pass is after reload, so we can't wait for RA to handle it for us.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #2 from Daniel Santos ---
Another problem when we throw in an ms to sysv call:
$ cat /home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c
/* { dg-do compile { target lp64 } } */
/* { dg-options "-Ofast -mstackrealign -mabi=ms" } */
void __attribute__((sysv_abi)) a (char *);
void
b ()
{
char c[100];
c[1099511627776] = 'b';
a (c);
a (c);
}
spawn
/home/daniel/proj/sys/gcc/builds/pr82002-minimal-x86_64-pc-linux-gnu/gcc/xgcc
-B/home/daniel/proj/sys/gcc/builds/pr82002-minimal-x86_64-pc-linux-gnu/gcc/
/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -mstackrealign
-mabi=ms -S -o pr82002-2a.s
/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c: In
function 'b':
/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c:12:1:
error: unrecognizable insn:
(insn/f 36 35 37 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 116 [0x2540be410])) [2 S16 A128])
(reg:V4SF 27 xmm6))
"/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c":7 -1
(expr_list:REG_DEAD (reg:V4SF 27 xmm6)
(expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 116 [0x2540be410])) [2 S16 A128])
(reg:V4SF 27 xmm6))
(nil
during RTL pass: cprop_hardreg
/home/daniel/proj/sys/gcc/git/gcc/testsuite/gcc.target/i386/pr82002-2a.c:12:1:
internal compiler error: in extract_insn, at recog.c:2306
0x5c1958 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/daniel/proj/sys/gcc/git/gcc/rtl-error.c:108
0x5c1974 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/daniel/proj/sys/gcc/git/gcc/rtl-error.c:116
0xba05a9 extract_insn(rtx_insn*)
/home/daniel/proj/sys/gcc/git/gcc/recog.c:2306
0xba15e8 extract_constrain_insn(rtx_insn*)
/home/daniel/proj/sys/gcc/git/gcc/recog.c:2206
0xbaaaf6 copyprop_hardreg_forward_1
/home/daniel/proj/sys/gcc/git/gcc/regcprop.c:801
0xbab8a4 execute
/home/daniel/proj/sys/gcc/git/gcc/regcprop.c:1308
I guess we don't have a 64-bit offset instruction for (v)movabs :)
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #1 from Daniel Santos ---
(In reply to Martin Liška from comment #0)
> Starting from r251321 we ICE on:
>
> $ cat stack-check.ii
> void a (char *);
> void
> b ()
> {
> char c[100];
> c[1099511627776] = 'b';
> a (c);
> a (c);
> }
>
> $ g++ stack-check.ii -Ofast -mstackrealign -mabi=ms
Thanks for the report! I added a new check to catch things that shouldn't be
and it this is good because this invokes a code path that hadn't gotten yet.
if (TARGET_64BIT
&& m->fs.sp_offset > 0x7fff
&& sp_valid_at (frame.stack_realign_offset)
&& (frame.nsseregs + frame.nregs) != 0)
{
pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
GEN_INT (m->fs.sp_offset
- frame.sse_reg_save_offset),
style,
m->fs.cfa_reg == stack_pointer_rtx);
}
The 3rd test in that if statement used to be m->fs.sp_valid, but I changed the
way we manage that so that it's valid for some offsets but not others. I think
that this should be sp_valid_at (frame.stack_realign_offset + 1) however --
stack-grows-down math is still new and weird to me. I'll spend some more time
with this tomorrow, but I think that one change is correct.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |8.0
