[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 Dzianis Kahanovich changed: What|Removed |Added Attachment #47753|0 |1 is obsolete|| --- Comment #102 from Dzianis Kahanovich --- Created attachment 47874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47874=edit additional aligning on demand <10.0 (fixed) Sorry (choked), playing with 10.0 I lost mind... 9.2 patch was broken. There are fixed.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #101 from Dzianis Kahanovich --- Created attachment 47754 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47754=edit additional aligning on demand 10.0 (unsure) This is same for gcc 10.0 and not fully verifyed. It MUST work in gcc 10.0, but in current git options helps show nothing changed: gcc -Q -O3 -m32 -march=core2 --help=target --help=optimizers |grep 'stackrealign\|cost-model' Looks like deep options behaviour rework in progress.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #100 from Dzianis Kahanovich --- Created attachment 47753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47753=edit additional aligning on demand <10.0 Finally (for me), if somebody think to patch by H.J. Lu is not enough, there are my patch to force "-fvect-cost-model=cheap -fsimd-cost-model=cheap" or "-mstackrealign" on demand. Default - first, as no abi violation, but if defined ENABLE_STACKREALIGN_ABI_VIOLATION=1 - first choice will be "-mstackrealign". This is for gcc <10.0 and verifyed.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #99 from Dzianis Kahanovich --- PPS About some hidden thinks/things. In pure theory. "*cost-model=cheap" can reduce SSE usage, -mstackrealign - can increase function prolog/epilog overhead. In my case - x7-Z8700 CPU have 2 FPU cores for 4 CPU cores (silvermont-1 have even less FPUs), so solution looks sure better then "-mstackrealign". But on some other CPUs something may be else and need to be tested about performance.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #98 from Dzianis Kahanovich --- fix: "I not try to rebuild 32bit "world" without ANY workaround" - on modern gcc (now all under 9.2). Previous experiments was times & versions ago, so many other new factors/fixes can solve most issues.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #97 from Dzianis Kahanovich ---
No. Looking into gcc/opts.c - "-O3 optimizations" section - line:
{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL, VECT_COST_MODEL_DYNAMIC },
- so, for -O3 it's "dynamic". Then, RTFM, "cheap" more cares about aligning.
But anymore, I not try to rebuild 32bit "world" without ANY workaround, so all
still dirty ;)
PS For some options configuration behaviour still non-linear, so queryng "gcc
-Q ..." still unsafe to check some defaults...
(In reply to Viktor Ostashevskyi from comment #96)
> Honestly, I don't see how your compiler flags could help. cost-model=cheap
> is default, data-alignment doesn't change incoming stack alignment.
>
> ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by <
> gcc-bugzi...@gcc.gnu.org> пише:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
> >
> > --- Comment #95 from Dzianis Kahanovich ---
> > Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace
> > Gentoo),
> > I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap
> > -fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3
> > +.
> > (This is dirty example, as cacheline for some old SSE CPUs are different,
> > etc).
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #95 from Dzianis Kahanovich --- Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace Gentoo), I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap -fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3 +. (This is dirty example, as cacheline for some old SSE CPUs are different, etc).
[Bug tree-optimization/69458] New: [graphite] compiling gmp -floop-nest-optimize over -fstrict-overflow produces wrong code (fpe)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69458 Bug ID: 69458 Summary: [graphite] compiling gmp -floop-nest-optimize over -fstrict-overflow produces wrong code (fpe) Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mahatma at eu dot by Target Milestone: --- After rebuild gmp (6.1.0 now) with -floop-nest-optimize over -O2 or -O1 -fstrict-overflow - gmp broken (gcc floating point exception). IMHO same was time ago with older versions of all. amd64. Same with +- asm & pgo.
[Bug tree-optimization/53966] procmail build deadloop on _autotst -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 --- Comment #3 from Dzianis Kahanovich mahatma at eu dot by 2012-07-16 13:15:50 UTC --- (In reply to comment #2) Yes, right, -O2 -finline-functions broken too. -O3 -fno-inline-functions - broken; -O3 -fno-inline-functions -fno-ipa-cp-clone - good. -fno-strict-aliasing and/or -fwrapv - I found no differences in all combinations.
[Bug c/53966] New: procmail build deadloop on _autotst -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 Bug #: 53966 Summary: procmail build deadloop on _autotst -O3 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: maha...@eu.by Building procmail 3.22 with -O3 or -O2 -fipa-cp-clone cause deadloop on _autotest. But - subproblem - -O3 -fno-ipa-cp-clone cause deadloop too. To reproduce: cd procmail-3.22/src 1) make CFLAGS=-O3 2) make CFLAGS=-O2 -fipa-cp-clone 3) make CFLAGS=-O3 -fno-ipa-cp-clone 4) make CFLAGS=-O2 - only (4) is good.
[Bug c/53966] procmail build deadloop on _autotst -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 --- Comment #1 from Dzianis Kahanovich mahatma at eu dot by 2012-07-14 20:49:30 UTC --- x86_64
[Bug regression/52225] New: -minline-all-stringops possible stuck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52225 Bug #: 52225 Summary: -minline-all-stringops possible stuck Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: maha...@eu.by Under gentoo long times (ago) I use -minline-all-stringops system-wide at least on x86_64. After one of version of gcc (not remember, IMHO probably near 4.3) I got error on x86_32 (p4) - I remember only stuck on build. After crazy hunting I just say in all my make.conf -mno-inline-all-stringops to remember it is bad and forget sense. Now on 4.6.2 x86_64 nocona I trying to return -minline-all-stringops. I got stuck on tdb build (configure) and just one time. This is too problematic to rebuild all (working) systems for bound this random problem, then just FYI. Current nocona CFLAGS: CFLAGS=-Wl,--no-keep-memory -O3 -mtune=native -march=native -Wa,-mtune=nocona -pipe -fexcess-precision=fast -mfpmath=both -funroll-loops -fpeel-loops -fomit-frame-pointer -fivopts -floop-optimize -maccumulate-outgoing-args -ftree-loop-linear -ftracer -w -findirect-inlining -ftree-switch-conversion -fno-dwarf2-cfi-asm -fconserve-stack -fsection-anchors -fmodulo-sched -fmodulo-sched-allow-regmoves -freschedule-modulo-scheduled-loops -fgcse-sm -fgcse-las -fgcse-after-reload -fsee -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fvect-cost-model -fgraphite-identity and+: -fgcse-after-reload -fipa-cp-clone -fpredictive-commoning -ftree-loop-distribute-patterns -ftree-vectorize -funswitch-loops - for packages filtering -O3 May be there ar sse problem (I use similar CFLAGS with -mstackrealign on x86_32 too). There are no problems without -minline-all-stringops.
[Bug target/52225] -minline-all-stringops possible stuck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52225 --- Comment #3 from Dzianis Kahanovich mahatma at eu dot by 2012-02-13 15:35:08 UTC --- OK, I will try to reproduce problem on chrooted environment (I rebuild system on this machine).
[Bug target/52225] -minline-all-stringops possible stuck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52225 --- Comment #4 from Dzianis Kahanovich mahatma at eu dot by 2012-02-13 15:49:43 UTC --- (In reply to comment #1) Can you explain what you mean by stuck? Also all those flags look like you are trying to test out the compiler and not really the system. PS this is why I hate gentoo, it tries to be the distro which wants speed by testing out the compiler options without actually a big warning about all -O2 flags by the user that they might run into issues. I mean by stuck (not precise, visual reconstruction): /configure Checking for program gcc or cc : /usr/bin/gcc Checking for program cpp : /usr/bin/cpp Checking for program ar : /usr/bin/ar Checking for program ranlib : /usr/bin/ranlib Checking for gcc : ok Checking for program git : /usr/bin/git Check for -MD: And all - infinite waiting. But configure under emerge sys-libs/tdb and not every try. I don't dig inside becouse this is secondary server in drbd cluster and I do not want long unstable state for it (emerge -eq system in progress). And I beleave - this problem will be founded not inside tdb package, but there are just IMHO. PS You can hate Gentoo and I can not use all good flags, but there are real flags on many my systems and there are no problems on x86_32 x86_64 (with some patches). You can comment bad flags if you don't fear to be offtopic.
[Bug target/52225] -minline-all-stringops possible stuck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52225 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Dzianis Kahanovich mahatma at eu dot by 2012-02-13 16:22:26 UTC --- If I was not right - sorry, I just poor remember old problem and get similar one, but now after emerge -eq world no packages with -minline-all-stringops keeped - I grepping in /var/db/pkg and reboot system. But problem still persist. There are only this stucked ;) tdb: http://mahatma.bspu.unibel.by/download/transit/tdb-build.tar.bz2 (from /var/tmp/portage/sys-libs/). I am sorry for this invalid report... But I just say -mno-... to this option to remember something from p4... ;( May be there are other gcc bug or other non-gcc bug...
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Attachment #22444|0 |1 is obsolete|| --- Comment #8 from Dzianis Kahanovich mahatma at eu dot by 2011-04-15 16:30:58 UTC --- Created attachment 23999 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23999 atune-4.6.patch Cleanup (+ unused macros), reduce code (ASM_SPEC_MTUNE moved to i386.h), adopt to 4.6.
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #87 from Dzianis Kahanovich mahatma at eu dot by 2011-03-13 16:56:05 UTC --- (In reply to comment #85) Am I the only one who thinks this bug should be nominated as the first priority GCC 4.6.0 bug? Some lazy people ;) may use global mstackrealign [patch] instead and remind only if some new package breaks in asm code on mstackrealign. But it is too old known problem to doubts about it priority. Really I found first package with mstackrealign problem, exclude gcc/libunwind - gst-ffmpeg-0.10.11/libavcodec (in Gentoo, may be other similar ebuilds just filtering sse/cpu options).
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Attachment #22434|0 |1 is obsolete|| --- Comment #7 from Dzianis Kahanovich mahatma at eu dot by 2010-11-18 12:31:25 UTC --- Created attachment 22444 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22444 atune2.patch Bugfix targets.
[Bug target/45359] poor -march=native choices for VIA C7 Esther processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Attachment #22306|0 |1 is obsolete|| --- Comment #5 from Dzianis Kahanovich mahatma at eu dot by 2010-11-18 13:05:51 UTC --- Created attachment 22445 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22445 centaur2.patch Compatibility with GNU assembler -mtune set (#40171).
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 --- Comment #6 from Dzianis Kahanovich mahatma at eu dot by 2010-11-17 19:15:10 UTC --- Created attachment 22434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22434 atune.patch Yes, I read maillist archives. But I don't know current state of process and may suggest own solution (best for me). Sorry if not actual. I pass only native march|mtune|Wa,-mtune - driver-i386.c -mtune results set are more compatible with GAS -mtune. And host_detect_local_cpu changed to process astune parameter and few (atom generic) incompatible keywords. There are only linux64.h changed. Others - likewise if somebody find this useful. patch produced on 5.0, but used on 4.5.
[Bug driver/46396] New: gcc not detect caches for VIA CPUs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46396 Summary: gcc not detect caches for VIA CPUs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: maha...@eu.by Created attachment 22346 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22346 via_caches.patch gcc not detect caches for VIA CPUs. But this task is too simple: according to Linux kernel code, detect_caches_amd function code is not so vendor-specific, and used in kernel also for any x86_64, VIA/Centaur, Transmeta and Cyrix family-5/model-5. By some reasons (actual tech) I suggest only code for VIA/Centaur CPUs (works fine for C7). This patch sure applicable to 4.5 trunk branches and must for any.
[Bug driver/46396] gcc not detect caches for VIA CPUs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46396 --- Comment #1 from Dzianis Kahanovich mahatma at eu dot by 2010-11-09 15:18:04 UTC --- PS If you think it possible, you may use more complex (+1 hunk) VIA detection patch, attached to Bug #45359.
[Bug target/45359] poor -march=native choices for VIA C7 Esther processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Attachment #0|0 |1 is obsolete|| --- Comment #4 from Dzianis Kahanovich mahatma at eu dot by 2010-11-07 10:47:13 UTC --- Created attachment 22306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22306 centaur.patch Just cleanup (c3-2). -mtune not passed to assembler, then -mtune vs. NOPL (by Gentoo Wiki) is not useful. May be -Wa,-mtune=generic or -Wa,, but not here...
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added CC||mahatma at eu dot by --- Comment #5 from Dzianis Kahanovich mahatma at eu dot by 2010-11-07 16:15:37 UTC --- (In reply to comment #0) Even Linux kernel use -march without -Wa,-march. If I pass -Wa,-march=prescott option to Linux kernel - they failed to build (used wide range of directives like AMD's prefetch). IMHO only -mtune need to be passed to not bound directives range.
[Bug target/45359] poor -march=native choices for VIA C7 Esther processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 --- Comment #3 from Dzianis Kahanovich mahatma at eu dot by 2010-11-01 13:21:40 UTC --- Created attachment 0 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=0 native VIA/CentaurHauls (In reply to comment #1) Why do you think it's a poor choice? This is regression after PR target/44046. Previous behaviour was: sse3 - -march=prescott -mtune=generic, now: sse3 - -march=pentium-m -mtune=generic. This regression lose sse3 support for C-7 CPU. But in other point, prescott as family-15 member, may be (or not) else scheduled, then family-6 clone... Other source of problem - VIA/Centaur CPUs detecting as Intel vendor. I believe, Intel support have own reason to make choice sse3 - pentium-m and lose this sse3, then I suggest to forget this behaviour and add native VIA/CentaurHauls support code. There are 3 point of detection: 1) vendor signature; 2) cache detection: according to Linux kernel code, detect_caches_amd behaviour is not vendor-specific and used in kernel also for any x86_64, VIA/Centaur, Transmeta and Cyrix family-5/model-5, but I have no exotic CPUs exclude VIA C-7 in my notebook to test other vendors; 3) model detection - C-7 will be -march=prescott -mtune=core2 (FIXME if pure prescott is better!), also may be fixed c3-2 -mtune=c3 selection (Gentoo Wiki suggest -mtune=generic or -march=c3 to avoid NOPL for some models, but I try to not use variable generic).
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added CC||mahatma at eu dot by --- Comment #12 from Dzianis Kahanovich mahatma at eu dot by 2010-11-01 13:22:26 UTC --- This patch produced regression, described (and more) in Bug 45359
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #28 from mahatma at eu dot by 2009-11-27 12:45 --- 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: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #29 from mahatma at eu dot by 2009-11-27 12:49 --- Created an attachment (id=19162) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19162action=view) (2) for 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #30 from mahatma at eu dot by 2009-11-27 12:51 --- Created an attachment (id=19163) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19163action=view) (2) for 4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #57 from mahatma at eu dot by 2009-10-15 14:29 --- (In reply to comment #53) Created an attachment (id=18656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656action=view) [edit] An updated patch for gcc 4.4 Oops. Wrong patch. Trry this one. Looks good for me. No segfaults while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #26 from mahatma at eu dot by 2009-10-13 12:16 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #27 from mahatma at eu dot by 2009-10-13 13:26 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #23 from mahatma at eu dot by 2009-10-12 11:40 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #20 from mahatma at eu dot by 2009-10-10 13:48 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #21 from mahatma at eu dot by 2009-10-10 13:51 --- Created an attachment (id=18773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18773action=view) tests proposal from PR 40838 (from H.J. Lu) Are there are good? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #12 from mahatma at eu dot by 2009-10-09 14:07 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #13 from mahatma at eu dot by 2009-10-09 14:08 --- Created an attachment (id=18761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18761action=view) 1) sse-stackrealign-misalignsse-4.4.patch -- mahatma at eu dot by changed: What|Removed |Added Attachment #18650|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #14 from mahatma at eu dot by 2009-10-09 14:09 --- Created an attachment (id=18762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18762action=view) 2) sse-stackrealign-sse4a-4.4.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #15 from mahatma at eu dot by 2009-10-09 14:10 --- Created an attachment (id=18763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18763action=view) 1) sse-stackrealign-misalignsse-4.5.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #16 from mahatma at eu dot by 2009-10-09 14:10 --- Created an attachment (id=18764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18764action=view) 2) sse-stackrealign-sse4a-4.5.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #17 from mahatma at eu dot by 2009-10-09 14:39 --- Created an attachment (id=18765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18765action=view) (2) for 4.4, fixed -- mahatma at eu dot by changed: What|Removed |Added Attachment #18762|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #18 from mahatma at eu dot by 2009-10-09 14:41 --- Created an attachment (id=18766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18766action=view) (2) for 4.5, fixed Originals may produce illegal warnings without SSE. -- mahatma at eu dot by changed: What|Removed |Added Attachment #18764|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #11 from mahatma at eu dot by 2009-09-25 11:03 --- Created an attachment (id=18650) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18650action=view) 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? -- mahatma at eu dot by changed: What|Removed |Added Attachment #18608|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #45 from mahatma at eu dot by 2009-09-23 18:37 --- (In reply to comment #41) Created an attachment (id=18618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18618action=view) [edit] An updated patch for gcc 4.4 Seamonkey still segfault. Still required -mstackrealign. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/41025] v4.3.3, 4.4.1, etc -ftracer sometimes fails by is already defined
--- Comment #2 from mahatma at eu dot by 2009-09-21 13:08 --- (In reply to comment #1) Can you provide the preprocessed source? Yes. After make/error: http://mahatma.bspu.unibel.by/download/transit/glibc-2.10.1-error.tar.bz2 (gentoo flavored, sorry) New info: it happened on -O2 or -O3, and never on -Os. Also I found how to get same on linux kernel x86_64: make defconfig, but remove optimize for size (CONFIG_CC_OPTIMIZE_FOR_SIZE) and add -ftracer. My working config do not produce this. Next I attaching Makefile. You will need only make defconfig make all on x86_64 for vanilla 2.6.31 kernel (IMHO simpler then glibc). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025
[Bug target/41025] v4.3.3, 4.4.1, etc -ftracer sometimes fails by is already defined
--- Comment #3 from mahatma at eu dot by 2009-09-21 13:12 --- Created an attachment (id=18623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18623action=view) linux-2.6.31 deconfig x86_64 error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #9 from mahatma at eu dot by 2009-09-19 16:12 --- Created an attachment (id=18608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18608action=view) 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 === -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #8 from mahatma at eu dot by 2009-09-08 12:08 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #31 from mahatma at eu dot by 2009-08-27 19:17 --- Seamonkey still more unstable then with 4.3.3. With system libs, -O3 sse - ruuning only in safe-mode. All system rebuilt with 4.4.1 this patch. There are looks like seamonkey problem (and I will add -mno-sse into ebuild for 4.4), but 4.3.3 or -mno-sse (all for seamonkey only) solving problem (4.3.3 regression patch no result too). IMHO in some situation(s) stack still unaligned. If I will find some more precise - I will say... PS Also IMHO must be checked with -msseregparm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #1 from mahatma at eu dot by 2009-08-25 10:20 --- Fix: I got bug with -msse only, not -msse2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #29 from mahatma at eu dot by 2009-08-19 19:08 --- (In reply to comment #28) ... This is not mine and isn't needed. OK. New patch working. While only so (tested in seamonkey with all included libs). Are realigning needed for both states of TREE_STATIC (decl)? Now in tree-vectorizer.c for i386 IMHO for both states are return (alignment = MAX_OFILE_ALIGNMENT); (by fact, IMHO). But old Bug 32893 solution was only for false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #27 from mahatma at eu dot by 2009-08-18 11:28 --- (In reply to comment #26) *** Bug 40985 has been marked as a duplicate of this bug. *** (In reply to comment #25) Created an attachment (id=18393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18393action=view) [edit] A patch for gcc 4.4 Are this patch may conflict with your patch? http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340action=view - equal to 32893 solution. I found, once you are broke (make regression) 4.4 branch against 32893 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893#c23 - I found there are your, sorry). May be this is way to suggest more correct sse solution vs. local bugfix for 32893, but while I not understand all - I trying to use both patches. May it be wrong? PS One more sorry, but I want to know ALL ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug tree-optimization/40985] [4.4 regression] Bug 32893 come back (-msse -ftree-vectorize cause segfaults (zlib))
--- Comment #9 from mahatma at eu dot by 2009-08-11 12:49 --- Simplest way to save Bug 32893 solution: replace MAX_STACK_ALIGNMENT by STACK_BOUNDARY in vect_can_force_dr_alignment_p (tree-vectorizer.c / ...). No error more. -- mahatma at eu dot by changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|-msse -ftree-vectorize cause|[4.4 regression] Bug 32893 |segfaults (zlib)|come back (-msse -ftree- ||vectorize cause segfaults ||(zlib)) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug tree-optimization/40985] [4.4 regression] Bug 32893 come back (-msse -ftree-vectorize cause segfaults (zlib))
--- Comment #10 from mahatma at eu dot by 2009-08-11 13:00 --- Created an attachment (id=18340) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340action=view) patch For gcc 4.4.1. Moved to tree-vect-data-refs.c in cvs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug c/41025] New: v4.3.3, 4.4.1, etc -ftracer sometimes fails by is already defined
-ftracer on various gcc versions sometimes gives is already defined error on build. Was on glibc (x86_*) linux kernel (x86_64), but now git-kernel build good and I not going deep. Only glibc 2.10.1 log tail: === [...] i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/dl-execstack.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -fPIC -g0 -O99 -fomit-frame-pointer -D__USE_STRING_INLINES-I../include -I/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf -I/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DNOT_IN_libc=1 -DIS_IN_rtld=1 -pipe -fomit-frame-pointer -ftracer -U_FORTIFY_SOURCE -U_FORTIFY_SOURCE -o /var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os.dt -MT /var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os ../sysdeps/unix/sysv/linux/dl-execstack.c: Assembler messages: ../sysdeps/unix/sysv/linux/dl-execstack.c:163: Error: symbol `__i686.get_pc_thunk.cx' is already defined make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.10.1/work/build-default-i686-pc-linux-gnu-nptl/elf/dl-execstack.os] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.10.1/work/glibc-2.10.1/elf' make[1]: *** [elf/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.10.1/work/glibc-2.10.1' make: *** [all] Error 2 === -- Summary: v4.3.3, 4.4.1, etc -ftracer sometimes fails by is already defined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mahatma at eu dot by GCC host triplet: i686-pc-linux-gnu-gcc, x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025
[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #23 from mahatma at eu dot by 2009-08-10 17:48 --- (In reply to comment #17) URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129764 Log: PR tree-optimization/32893 * tree-vectorize.c (vect_can_force_dr_alignment_p): Check STACK_BOUNDARY instead of PREFERRED_STACK_BOUNDARY. In 4.4 STACK_BOUNDARY changed to MAX_STACK_ALIGNMENT in this place. MAX_STACK_ALIGNMENT is STACK_BOUNDARY by default, but in i386.h: #define MAX_STACK_ALIGNMENT MAX_OFILE_ALIGNMENT I not check code dependences more, but starting from 4.4.0 this error alive (Bug 40985). Are there are regression or something else? PS May be reopen this bug with other version or Bug 40985 as regression report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)
--- Comment #7 from mahatma at eu dot by 2009-08-07 18:21 --- (In reply to comment #6) You can try my patch for PR 40838. No error. Current i386.h must be fixed by hands. Next I attach gcc-4.4.1 version of this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)
--- Comment #8 from mahatma at eu dot by 2009-08-07 18:24 --- Created an attachment (id=18325) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18325action=view) PR 40838 for gcc 4.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug tree-optimization/40985] New: -msse -ftree-vectorize cause segfaults (zlib)
Primary combination: -march=pentium4 -O3 ..., minimal: -O1 -march=i686 -msse -ftree-vectorize. Rebuilding zlib v1.2.3 cause segfault on related apps (I use seamonkey, all under gentoo). All other apps built on pentium4/O3/gcc4.3.3. -- Summary: -msse -ftree-vectorize cause segfaults (zlib) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mahatma at eu dot by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)
--- Comment #2 from mahatma at eu dot by 2009-08-06 13:49 --- (In reply to comment #1) Please follow [1] on how to report bug. [1] http://gcc.gnu.org/bugs.html With pleasure. If I will understand what I may to say more/else, exclude host type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)
--- Comment #5 from mahatma at eu dot by 2009-08-06 19:56 --- (In reply to comment #3) (In reply to comment #0) Primary combination: -march=pentium4 -O3 ..., minimal: -O1 -march=i686 -msse -ftree-vectorize. Rebuilding zlib v1.2.3 cause segfault on related apps (I use seamonkey, all under gentoo). All other apps built on pentium4/O3/gcc4.3.3. Please add -mincoming-stack-boundary=2 to CFLAGS and report what you got. No error. PS A read 32893, but have no errors prior to v4.4.0 and think there are not same bug, sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
