https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #10 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Jan 10 15:37:49 2018
New Revision: 256436
URL: https://gcc.gnu.org/viewcvs?rev=256436&root=gcc&view=rev
Log:
i386: Also adjust stack frame for stack slot alignment
We should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #9 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00678.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #8 from H.J. Lu ---
I am testing this patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8696f931806..8558995e067 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11259,7 +11259,8 @@ ix86_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #7 from Jakub Jelinek ---
Yes, but those saves should be to slots chosen earlier by
ix86_compute_frame_layout, shouldn't they. And then the question is why it
chose a frame size that isn't multiple of the needed alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #6 from H.J. Lu ---
push comes from
13174 if (!int_registers_saved)
13175 {
13176 /* If saving registers via PUSH, do so now. */
13177 if (!frame.save_regs_using_mov)
13178 {
13179 ix8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #5 from H.J. Lu ---
In main (), various RTL passes generate
(insn/f 461 460 462 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 3 bx)) "x.i":17 61 {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #4 from Jakub Jelinek ---
BTW, -O3 -mavx512bw ins't needed, e.g. -O3 -mavx reproduces it too.
The function doesn't really need DRAP or stack realignment, but because
stack_alignment_needed is 128, better should make sure that sp is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #3 from Jakub Jelinek ---
The n variable is 128-bit aligned and lives on the stack, so it is unclear why
the stack realignment code misses that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
--- Comment #2 from Jakub Jelinek ---
But again succeeds with -mno-stv, so likely dup of PR83330.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83735
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
12 matches
Mail list logo
