[hjl@gnu-6 880]$ cat x.c extern int foo (); int main() { return foo(); } [hjl@gnu-6 880]$ rm x.s [hjl@gnu-6 880]$ cat x.c extern int foo (); int main() { return foo(); } [hjl@gnu-6 880]$ make /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ -O2 -m32 -S -o x.s x.c [hjl@gnu-6 880]$ cat x.s .file "x.c" .text .p2align 4,,15 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp leave jmp foo The stack isn't aligned to 16byte. .size main, .-main
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00670.html
An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00724.html
I changed it to middle-end.
Confirmed.
The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00130.html
The current patch is at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html
P1 bug with a pending patch... maybe a reviewer could take a look at this (seemingly trivial) patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html ?
Subject: Bug 37843 Author: hjl Date: Tue Nov 25 15:33:27 2008 New Revision: 142193 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142193 Log: gcc/ 2008-11-25 H.J. Lu <hongjiu.lu@intel.com> Joey Ye <joey.ye@intel.com> PR middle-end/37843 * config/i386/i386.c (ix86_function_ok_for_sibcall): Return false if we need to align the outgoing stack. (ix86_update_stack_boundary): Check parm_stack_boundary. gcc/testsuite/ 2008-11-25 H.J. Lu <hongjiu.lu@intel.com> PR middle-end/37843 * gcc.target/i386/align-main-3.c: New. * gcc.target/i386/pr37843-1.c: Likewise. * gcc.target/i386/pr37843-2.c: Likewise. * gcc.target/i386/pr37843-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/align-main-3.c trunk/gcc/testsuite/gcc.target/i386/pr37843-1.c trunk/gcc/testsuite/gcc.target/i386/pr37843-2.c trunk/gcc/testsuite/gcc.target/i386/pr37843-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
On i686-apple-darwin9, we are failing... FAIL: gcc.target/i386/pr37843-1.c scan-assembler call[\\t ]*foo FAIL: gcc.target/i386/pr37843-2.c scan-assembler jmp[\\t ]*foo at revision 142207.
Created attachment 16773 [details] assembly file for gcc.target/i386/pr37843-1.c on i686-apple-darwin9 Created with... /sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-1.c -O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=5 -S -m32 -o pr37843-1.s
Created attachment 16774 [details] assembly file for gcc.target/i386/pr37843-2.c on i686-apple-darwin9 Created with... /sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-2.c -O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=6 -S -m32 -o pr37843-2.s
I don't think sibcall work on Darwin. Can you skip them on Darwin?
Why do we have... /* { dg-do compile { target { *-*-linux* && ilp32 } } } */ in gcc.target/i386/align-main-3.c and gcc.target/i386/pr37843-3.c but not gcc.target/i386/pr37843-1.c and gcc.target/i386/pr37843-2.c? Isn't that the origin of the problem on darwin?
Subject: Bug 37843 Author: hjl Date: Wed Nov 26 14:52:12 2008 New Revision: 142222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142222 Log: 2008-11-26 H.J. Lu <hongjiu.lu@intel.com> PR middle-end/37843 * gcc.target/i386/pr37843-1.c: Make it Linux only. * gcc.target/i386/pr37843-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr37843-1.c trunk/gcc/testsuite/gcc.target/i386/pr37843-2.c
Subject: Bug 37843 Author: hjl Date: Fri Nov 28 16:30:56 2008 New Revision: 142259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142259 Log: 2008-11-28 H.J. Lu <hongjiu.lu@intel.com> PR middle-end/37843 * gcc.target/i386/pr37843-1.c: Make it nonpic targets only. * gcc.target/i386/pr37843-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr37843-1.c trunk/gcc/testsuite/gcc.target/i386/pr37843-2.c
Subject: Bug 37843 Author: hjl Date: Sat Nov 29 16:32:35 2008 New Revision: 142278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142278 Log: 2008-11-29 H.J. Lu <hongjiu.lu@intel.com> PR middle-end/37843 * gcc.target/i386/pr37843-3.c: Make it nonpic targets only. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr37843-3.c
Fixed.
It isn't totally fixed: FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[\\\\t ]*foo FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[\\\\t ]*foo I only checked in x86 backend change since no one has reviewed the middle-end change: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01309.html
Subject: Re: [4.4 Regression] unaligned stack in main due to tail call optimization On Sat, 29 Nov 2008, hjl dot tools at gmail dot com wrote: > ------- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:10 ------- > It isn't totally fixed: > > FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[\\\\t ]*foo > FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[\\\\t ]*foo > > I only checked in x86 backend change Which is if course not the right thing to do without XFAILing the new testcases... Richard.
HJ -- As Richard says, you should not have checked in the new testcases without XFAILs and without having fixed the bug. Furthermore, your patch to the middle-end is without explanation. What is the problem? How does your patch fix the problem? -- Mark
Created attachment 16868 [details] An updated patch This patch adds some comments to middle-end change. It also replaces _Decimal128 with __m128 in gcc.target/i386/pr37843-3.c so that it can run for all ia32 targets.
(In reply to comment #20) > HJ -- > > As Richard says, you should not have checked in the new testcases without > XFAILs and without having fixed the bug. > > Furthermore, your patch to the middle-end is without explanation. What is the > problem? How does your patch fix the problem? > Hi Mark, Thanks for looking into this. I uploaded a new patch at http://gcc.gnu.org/bugzilla/attachment.cgi?id=16868 with comments to middle-end changes.
Please s/incomoing/incoming/g in the patch. Otherwise the patch makes a lot of sense to me. As INCOMING_STACK_BOUNDARY is used not only in expand_stack_alignment, but also in 386's targetm.function_ok_for_sibcall (and i386 is the only target that has variable INCOMING_STACK_BOUNDARY ATM). This target hook is called from expand_call, indirectly from expand_gimple_basic_block. expand_stack_alignment is called after all the expand_gimple_basic_block calls, and the patch moves INCOMING_STACK_BOUNDARY initialization before those calls.
Created attachment 17107 [details] Here is the updated patch.
(In reply to comment #24) > Created an attachment (id=17107) [edit] > Here is the updated patch. OK. Diego.
Subject: Bug 37843 Author: hjl Date: Thu Jan 15 15:44:41 2009 New Revision: 143400 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143400 Log: gcc/ 2009-01-15 H.J. Lu <hongjiu.lu@intel.com> Joey Ye <joey.ye@intel.com> PR middle-end/37843 * cfgexpand.c (expand_stack_alignment): Don't update stack boundary nor check incoming stack boundary here. (gimple_expand_cfg): Update stack boundary and check incoming stack boundary here. gcc/testsuite/ 2009-01-15 H.J. Lu <hongjiu.lu@intel.com> PR middle-end/37843 * gcc.target/i386/pr37843-3.c: Replace _Decimal128 with __m128. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr37843-3.c
Fixed, thanks.