+++ This bug was initially created as a clone of Bug #32893 +++ Gcc 4.4/4.5 can align stack properly. But it needs to assume 4 byte incoming stack alignment instead of 16byte.
Fix: I got bug with -msse only, not -msse2.
Why is this considered a regression?
(In reply to comment #2) > Why is this considered a regression? > It is a regression for PR 32893, which was fixed by disabling vectorizer on local variables requiring > 4byte alignment since we couldn't realign the stack at the time to support 4byte incoming stack. With automatic stack alignment, this restricting was removed. But since we assume incoming stack is 16byte, we don't realign the stack. When incoming stack is 4 byte aligned, we get segfault.
HJ, this doesn't make sense. Either we can assume 16-byte stack alignment, or we can't. Which is it?
(In reply to comment #4) > HJ, this doesn't make sense. > > Either we can assume 16-byte stack alignment, or we can't. Which is it? > On ia32, except for MacOS, we don't enforce 16-byte stack alignment. We get 4-byte incoming stack alignment via object files: 1. Compiled with older gcc. 2. Compiled with gcc 3.x and earlier 4.x using -Os. 3. Compiled with gcc using -mpreferred-stack-boundary=2 4. From assembly code with 4 byte stack alignment. 5. Compiled with other compilers, which generate 4 byte stack alignment. It usually won't cause segfault until vectorizer is enabled.
IMHO either standard options compiled code shouldn't be called from -mpreferred-stack-boundary=2 code, or it needs to be compiled with -mincoming-stack-boundary=2. But it should be user's responsibility. Ensuring by default outgoing calls are 16 byte aligned, but not assuming it is just a very stupid thing to do and unnecessarily penalizes normal users. It is certainly not true that most code is compiled with -mpreferred-stack-boundary=2, only kernel and a handful of packages is by default, and kernel has its own ABI (and doesn't use FPU nor SSE*).
Realign the incoming stack for vectorizer has very limited impact on performance. Here are the differences of -m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops before and after my patch: 400.perlbench -0.384615% 401.bzip2 0% 403.gcc -0.362319% 429.mcf -0.813008% 445.gobmk 0.921659% 456.hmmer 0.549451% 458.sjeng -0.438596% 462.libquantum 0% 464.h264ref 0% 471.omnetpp -0.478469% 473.astar -0.645161% 483.xalancbmk -0.727273% SPECint(R)_base2006 -0.411523% 410.bwaves -0.406504% 416.gamess 0% 433.milc -1.36986% 434.zeusmp -0.44843% 435.gromacs 0% 436.cactusADM 0% 437.leslie3d -0.888889% 444.namd 1.20482% 447.dealII -0.350877% 450.soplex -0.31746% 453.povray 0.458716% 454.calculix 0% 459.GemsFDTD 0% 465.tonto 0% 470.lbm 0% 481.wrf 0.480769% 482.sphinx3 0.940439% SPECfp(R)_base2006 0% It won't change generated code if vectorizer isn't enabled. Its benifits outweigh its drawbacks.
I don't trying to rebuild all with 4-byte incoming stack alignment while, but think to unify this step with full ABI change. For me it may solve migration to -mregparm=3 ("ix86_regparm = REGPARM_MAX;" for x86_32) and others in crosscompile way (for example, to "i686-eabi-linux-gnu" target). For people it may solve "ABI standard" orthodox problem too. Most undiscovered place FOR ME (while I busy in other place): adding support to "eabi*" (1+*) keyword, eabi/eabi1 may be REGPARM_MAX + 4-byte incoming stack alignment (or even more safe solution) + any others safe (if exists) changes. eabi2 - hardcoded -msseregparm (I unsure in softfloat/no-sse compatibility, then there are must be optional), etc.
Created attachment 18608 [details] sse & 32bit -> -mstackrealign (example only!) Previous my ideas too heavy. :) IMHO native solution for this problem is "-mstackrealign". It solving problems with known to me packages (including zlib). I trying to make STACK_REALIGN_DEFAULT related from TARGET_SSE && !TARGET_64BIT (see patch). But got "internal compiler error" on gcc self-compiling with "-march=pentium4". Without sse (=without -mstackrealign) self-compiling works. Why -mstackrealign may be bad and why gcc dont' self-compiling so? Error: === /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -mtune=pentium4 -march=pentium4 -pipe -w -O2 -O2 -g -mtune=pentium4 -march=pentium4 -pipe -w -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/. -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../include -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind-c.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind-dw2.c:1555: /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind.inc:212: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:8570 ===
(In reply to comment #9) > Created an attachment (id=18608) [edit] > sse & 32bit -> -mstackrealign (example only!) > > Previous my ideas too heavy. :) > IMHO native solution for this problem is "-mstackrealign". It solving problems > with known to me packages (including zlib). I trying to make > STACK_REALIGN_DEFAULT related from TARGET_SSE && !TARGET_64BIT (see patch). But > got "internal compiler error" on gcc self-compiling with "-march=pentium4". > Without sse (=without -mstackrealign) self-compiling works. > > Why -mstackrealign may be bad and why gcc dont' self-compiling so? > Stack alignment in unwind library is unsupported.
Created attachment 18650 [details] sse & 32bit -> -mstackrealign (example 2) Second attempt (while against 4.4.1, sorry). Working with any -march. For gcc libc -mstackrealign disabled. Tell me: 1) how to isolate cflags for unwind-dw2.c or unwind library or stage1 (exclude preset STAGE1_LIBCFLAGS, etc before make)? 2) are misaligning may be happened in internal libs and when? (to "-mno-sse" or question 1) 3) are 3DNOW! must be realigned too? and what other sse-independent sets/targets must be realigned?
I found new AMD CPUs not required to stack aligning for SSE. IMHO there are "misalignsse" cpu feature, found near SSE4a (fixme). Then, requirement for stack realigning may be checked from "misalignsse" (precise) or "sse4a" (simple). I don't want (while) to exeperiments with make scripts for isolating "-mno-stackrealign" CFLAGS for unwinding library and only suggest two variants of common solution: 1) Checking "misalignsse" for -march=native, -mno-stackrealign (if given) may produce broken code with SSE, gcc libs not verifyed against it. 2) Use TARGET_SSE4A as "cname" to misalignsse to detect realigning requirement. Also trying to disable SSE if realigning forced to disable (-mno-stackrealign given). SSE for gcc libs will be disabled. This solutions may be mixed, but I see no sense. Or SSE4A is used or no. If no - I not found way to move "misalignsse" flag to configuration section. Just may be sense to remove SSE disabling in (2) - just remove i386.c changes. IMHO last todo in this case: unwinding library (CFLAGS or -mstackrealign support). PS Both are untested. But sse-stackrealign-1.patch have not problems for me. Both are
Created attachment 18761 [details] 1) sse-stackrealign-misalignsse-4.4.patch
Created attachment 18762 [details] 2) sse-stackrealign-sse4a-4.4.patch
Created attachment 18763 [details] 1) sse-stackrealign-misalignsse-4.5.patch
Created attachment 18764 [details] 2) sse-stackrealign-sse4a-4.5.patch
Created attachment 18765 [details] (2) for 4.4, fixed
Created attachment 18766 [details] (2) for 4.5, fixed Originals may produce illegal warnings without SSE.
Without a testcase, people may not review the patch.
(In reply to comment #19) > Without a testcase, people may not review the patch. > May be just include your tests from Bug 40838? (even without testing) From http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656 Your suggestions? I understand so there are same results with your gcc-4.4-pr40838-*.patch, but realigning whole code and exclude "misaligned" AMD CPUs. And warrantied to realign in any place. Your gcc-4.4-pr40838-3.patch lost realigning in unknown place - runtime segfaults in Seamonkey. *-4.patch I don't test becouse alredy use simple "-mstackrealign" solution - first there are dummy testing - surfing with Seamonkey until sometimes segfault, second - I got new desktop with Athlon (but was alredy satisfyed by "-mstackrealign" on old Celeron). Now I prefer to use safe "-mstackrealign" solution for Intel CPUs on 32bit servers and to be sure in safe SSE code. And see no visual defferences in perfomance whith global "-mstackrealign".
Created attachment 18773 [details] tests proposal from PR 40838 (from H.J. Lu) Are there are good?
(In reply to comment #20) > (In reply to comment #19) > > Without a testcase, people may not review the patch. > > > > May be just include your tests from Bug 40838? (even without testing) > From http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656 > Your suggestions? > > I understand so there are same results with your gcc-4.4-pr40838-*.patch, but > realigning whole code and exclude "misaligned" AMD CPUs. And warrantied to > realign in any place. > > Your gcc-4.4-pr40838-3.patch lost realigning in unknown place - runtime > segfaults in Seamonkey. *-4.patch I don't test becouse alredy use simple We can't check Seamonkey into gcc/testsuite. We need something much smaller. > "-mstackrealign" solution - first there are dummy testing - surfing with > Seamonkey until sometimes segfault, second - I got new desktop with Athlon (but > was alredy satisfyed by "-mstackrealign" on old Celeron). Now I prefer to use > safe "-mstackrealign" solution for Intel CPUs on 32bit servers and to be sure > in safe SSE code. And see no visual defferences in perfomance whith global > "-mstackrealign". > If you think adding -mstackrealign to your build is an acceptable solution, we can close this bug. Otherwise, please test my latest gcc 4.4 patch for PR 40838. Thanks.
(In reply to comment #22) > We can't check Seamonkey into gcc/testsuite. We need something > much smaller. I understand this. But even if I will use your testsuite addons (I unsure in it, Gentoo "USE=test emerge sys-deve/gcc" on unpatched gcc & Celeron don't breaks), unknown bug from at least old *-3.patch will be present. This is like communicative problem, but problem... > If you think adding -mstackrealign to your build is an acceptable solution, > we can close this bug. Otherwise, please test my latest gcc 4.4 patch for > PR 40838. Thanks. Your patch, by idea, more accurate - if now realign stack in ALL requred places. But also it unmotivated realign with AMDs too. I alredy ask: "Why -mstackrealign may be bad?". This is dark place. In manpage "-mstackrealign" described against SSE aligning problem. This is like wellknown solution, but unused wide. Why? What side-effects of "-mstackrealign"? Perfomance? Compatibility? Just ABI standard? Related from this "-mstackrealign" may be hardcoded for SSE in simple way - just "SSE -> -mstackrealign" or overcoded patch to disable -mstackrealign for AMDs. Or unuse whole. I will not fast testing your patch on old Celeron (after few days) to close this theme too, but for final solution IMHO information about -mstackrealign [history] required.
(In reply to comment #23) > > If you think adding -mstackrealign to your build is an acceptable solution, > > we can close this bug. Otherwise, please test my latest gcc 4.4 patch for > > PR 40838. Thanks. > > Your patch, by idea, more accurate - if now realign stack in ALL requred > places. But also it unmotivated realign with AMDs too. I alredy ask: "Why > -mstackrealign may be bad?". This is dark place. In manpage "-mstackrealign" > described against SSE aligning problem. This is like wellknown solution, but > unused wide. Why? What side-effects of "-mstackrealign"? Perfomance? Please see PR 40838.
would you please just test the patch on PR 40838 and tell HJ if it works or not?
(In reply to comment #25) > would you please just test the patch on PR 40838 and tell HJ if it works or > not? > In progress. There are only one Celeron PC leased without distcc to build and runtime test big packages.
(In reply to comment #24) > > unused wide. Why? What side-effects of "-mstackrealign"? Perfomance? > > Please see PR 40838. As seen on... a... I found only ABI standard reasons. FIXME! But SSE usage still optional like -mstackrealign option. I see no political differences: "-msse" or "-march=pentium4" or "-mstackrealign". Default "i686" builds will be same unaligned.
Yes, I read PR 40838. But last (IMHO) in this thread: Disabling SSE in whole GCC libs may cause various build problems in SSE-related -march (mostly with -ffast-math, but IMHO more). So, to use this simple solution, SSE disabling code better to remove. If still paranoid about GCC libs SSE compatibility - better to build GCC with "-march=i686". Next stripped patches:
Created attachment 19162 [details] (2) for 4.4
Created attachment 19163 [details] (2) for 4.5
I still have no idea what this PR is about. Someone needs to make a clear statement of what they believe the ABI to be. There are some simple questions: * Can we expect that the stack is 16-byte aligned, or not? * If we cannot (because of legacy requirements), then is there any reason to try to align the stack automatically at entry to every function, or at every call site? I can see that this might be useful as an option, but it does not seem like a sensible default to me.
(In reply to comment #31) > I still have no idea what this PR is about. Someone needs to make a clear > statement of what they believe the ABI to be. There are some simple questions: > > * Can we expect that the stack is 16-byte aligned, or not? Not if we want to be binary compatible with object files compiled by compilers, including gcc 1.x/2.x/3.x, which generate 4byte stack alignment. > > * If we cannot (because of legacy requirements), then is there any reason to > try to align the stack automatically at entry to every function, or at every > call site? I can see that this might be useful as an option, but it does not > seem like a sensible default to me. > See PR 40838. "-mstackrealign" now aligns the stack only if SSE vector instructions are used in the function. The performance impact of "-mstackrealign" is minimum: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c65
Subject: Re: [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize I believe the ABI *is* that the stack must be 16-byte aligned at function boundaries, although this is not documented other than as a statement of what GCC does <http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1>. This does not of course stop smaller alignment being used for particular code by private arrangement as long as 16-byte alignment is used when calling back into user code (for example, it's fine for glibc to build code not using callbacks with smaller alignment, or for the Linux kernel to use smaller alignment internally as long as it ensures the full alignment for signal frames in userspace processes).
Yeah, I completely agree with that.
Hello, I just upgraded to gcc-4.4.3 (from Gentoo distribution) and recompiled the whole system (on x86). Then I had to discover the (as it turned to be, infamous) mozilla-firefox + zlib bug. I reported it to the distribution here: http://bugs.gentoo.org/show_bug.cgi?id=323431 As I learned later, everybody accounts for incoming misaligned stack to be the cause of the crashes. But what I see: inflate_table: .LFB45: .file 1 "inftrees.c" .loc 1 39 0 .LVL0: pushl %ebp ; stack misaligned to -4 .LCFI0: .loc 1 108 0 pxor %xmm0, %xmm0 .loc 1 39 0 movl %esp, %ebp ; $ebp % 16 = 4 .LCFI1: pushl %edi .LCFI2: pushl %esi .LCFI3: pushl %ebx .LCFI4: call .L101 .L101: popl %ebx addl $_GLOBAL_OFFSET_TABLE_+[.-.L101], %ebx subl $188, %esp .LCFI5: .loc 1 108 0 movdqa %xmm0, -56(%ebp) ; -56-4=60, 60%16=4 ; <snip> Even if the stack were 16 bytes aligned on the entry, the instruction in the last line would attempt an unaligned access and thus would fault. Please correct me, if I miscounted. My concern is: even with ABI which guarantees 16-byte aligned incoming stacks, gcc generates code which would segfault.
Alexander, you're omitting to consider that call pushes EIP + 4 onto the stack. Thus on entry the stack is already misaligned by -4, so gcc is correct.
Thank you, Ed. I missed that. I wrongly (obviously wrongly, because this would negatively affect performance) thought that ABI is such that stack is aligned after the call, not before.
The conclusion seems to be WONTFIX (or NOT-A-BUG). Getting it off the serious regressions radar.