[Bug rtl-optimization/40838] New: gcc shouldn't assume that the stack is aligned

[Bug rtl-optimization/40838] New: gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

typedef int v4si __attribute__ ((vector_size (16)));

v4si y(v4si *s3)
{
        return *s3;
}

extern v4si s1, s2;

v4si x(void)
{
        v4si s3 = s1 + s2;
        return y(&s3);
}

And compile it with -O2 -fno-inline -msse2 -fomit-frame-pointer

The variable s3 is stored using unaligned store (movdqu) and loaded using
aligned load (movdqa). -mpreferred-stack-boundary=4 doesn't guarantee stack
alignment, it only advises that there is stack alignment (the function may be
called from OS callback, signal, another library compiled with lesser
alignment, etc... --- and i386 mandates only 4-byte stack alignment), so use of
movdqa is incorrect. (does GCC ABI mandate that all vector types must be
aligned? If so, then movdqa is correct, but storing it on the stack, relying on
alignment -mpreferred-stack-boundary=4 is not correct).

Now, if you compile it with -mpreferred-stack-boundary=2, function "x" aligns
the stack but uses movdqu to store on the aligned stack, so it generates
suboptimal code.


-- 
           Summary: gcc shouldn't assume that the stack is aligned
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2009-07-23 12:56 -------
Linux/ix86 ABI says that stack must be 16 byte aligned.  So GCC can rely on it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2009-07-23 13:13 -------


*** This bug has been marked as a duplicate of 38496 ***


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-23 13:15 -------
What I would propose to fix this and bug #40667:

Each type has required alignment and preferred alignment. Enforced alignment is
what is needed to not crash and not violate the ABI, preferred alignment is the
alignment that has the best performance. For i386, all the types have enforced
alignment 4-byte, except 128-bit SSE type having enforced alignment 16-bytes
(the movdqa instruction crashes otherwise). Preferred alignment is 8 for double
and 8-byte vector types and 16 for long double and 16-byte vector types.

Now, if the function has some variable with the enforced alignment greater than
the ABI standard (4), the stack must be realigned. The ABI mandates 4-byte
alignment and the function may be called from anywhere. As an optimization, the
realign may be skipped if the function is static and it is proved to be called
only from functions with greater or equal enforced alignment and having stack
size aligned.

Each function aligns its stack size to -mpreferred-stack-boundary, which
basically means "if the stack was aligned before (the most common case),
performance will be good". But you can't rely on this for correctness, as in
the pathological cases, the stack doesn't have to be aligned.

As an optimization, if you can prove that the function will call only functions
manipulating types with preferred alignment at most X and X is lower than
-mpreferred-stack-boundary, you can lower stack alignment to X (so that if
there's a call graph of functions using only "double", you don't have to align
the stack on the default 16 bytes, 8 bytes is sufficient).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-23 13:19 -------
"Linux/ix86 ABI says that stack must be 16 byte aligned."

No it doesn't. There is a plenty of Linux code that doesn't have the stack
aligned on 16-byte boundary. (at least anything that was compiled with the old
gcc that didn't have -mpreferred-stack-boundary switch).

Please don't change i386 ABI.

AFAIK only MacOSX/x86 enforced aligned stack.


-- 

mikulas at artax dot karlin dot mff dot cuni dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2009-07-23 13:24 -------
The ABI has changed 8+ years ago, you are coming too late.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #6 from hjl dot tools at gmail dot com  2009-07-23 13:43 -------


*** This bug has been marked as a duplicate of 39315 ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-23 13:49 -------
See bug #27537, quoting "GNU/Linux follows the SYSV x86 ABI which is
documented, maybe you cannot find it but it does exist. The SYSV x86 ABI says
the stack is aligned 4 byte aligned."

That bug seems to reappear.

As Agner noted, 16-byte stack alignment requirement also break compatibility
with Intel CC. I found even some part of current glibc that violates this
16-byte alignment (calling push %eax; call exit from the assembler without
aligning the stack size).

Another point: if gcc realigns the stack, why then use movdqu to store the
values on the stack? That is suboptimal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2009-07-23 13:54 -------
Please read Joseph's responses in PR38496.

If you are aware of places in glibc that don't maintain 16 byte stack
alignment, please report them.  Certainly calling glibc (or any other default
compiler flags compiled) library with non-16 byte aligned stack is a bug.

You are free to come up with a different ABI for the OS, but it will not be the
ABI everybody is using.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #9 from hjl dot tools at gmail dot com  2009-07-23 13:56 -------
(In reply to comment #7)
> 
> Another point: if gcc realigns the stack, why then use movdqu to store the
> values on the stack? That is suboptimal.
> 

This is a dup for PR 39315.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-23 14:36 -------
Jakub: so try that "test $15, %esp; jnz abort" at every function, as I proposed
in bug #38496. There are much more places that will trigger this. Just go catch
them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #11 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 01:00 -------
So I did this experiment whether the stack is aligned in current Linux
binaries.
I applied this patch for gcc, so that it crashes on function entry if the
function has stack not aligned on 16 bytes.

diff -urp gcc-4.4.1/gcc/varasm.c gcc-4.4.1-test-align/gcc/varasm.c
--- gcc-4.4.1/gcc/varasm.c      2009-03-17 21:18:21.000000000 +0100
+++ gcc-4.4.1-test-align/gcc/varasm.c   2009-07-25 16:18:11.000000000 +0200
@@ -1760,6 +1760,8 @@ assemble_start_function (tree decl, cons
   /* Standard thing is just output label for the function.  */
   ASM_OUTPUT_LABEL (asm_out_file, fnname);
 #endif /* ASM_DECLARE_FUNCTION_NAME */
+  if (!crtl->stack_realign_needed)
+         fputs("\tsubl\t$12, %esp\n\ttestl\t$15,
%esp\n\tjz\t99999f\n\tud2a\n99999:\taddl\t$12, %esp\n", asm_out_file);
 }

 /* Output assembler code associated with defining the size of the

--- and the results are terrifying:

Gcc didn't even bootstrap itself. It failed because it calls glibc function
obstack_init and it calls back to xmalloc - with misaligned stack. So I
compiled gcc without bootstrap and tried to compile glibc-2.7 with it. Glibc
compiles its integer-only code with -mpreferred-stack-boundary=2, so I changed
it to -mpreferred-stack-boundary=4.

Glibc didn't finish its build either (failed when running some self-compiled
scripts), but it at least produced libc.so.

So I tried to preload this libc.so with stack-alignment-checking to various
Linux binaries (with LD_PRELOAD) and see what happens.

Out of 95 binaries in /bin/, only 23 succeeded! The remaining crashed because
of glibc was called with unaligned stack. (the distribution is up-to-date
Debian Lenny).

The non-crashing binaries are:

bzip2recover, cpio, dmesg, fgconsole, fuser, kill, loadkeys, lsmod, lvnet,
mktemp, more (displays help only, crashes when attempting to display any file),
mount, mountpoint, mt, mt-gnu, nbd-server, pidof, ping, ping6, run-parts, sed,
su, tailf, umount

So anyone, who is saying that the stack is aligned to 16 bytes has his mind
disconnected from reality. It isn't.

I find it very unreasonable that GCC developers try to declare their own ABI
with aligned stack --- and that conflicts with what is being used by the
majority of Linux applications. GCC developers are trying to say that 3/4 of
programs in /bin/ are wrong because they don't align the stack.

I think you should really align the stack in the functions that do SSE math and
don't rely on the fact that the stack is already aligned. It is definitelly
easier to use the code for stack reallign than declaring that majority of Linux
binaries are BAD and need to be recompiled.

If some scientists needed extreme performance and can't take the penalty of
realigning the stack, you can add an option -massume-aligned-stack form them
and it is the responsibility of a given scientist that the code compiled with
this option is never called back from libc or anything else else. But don't
assume stack alignment for general code. It just isn't true.


-- 

mikulas at artax dot karlin dot mff dot cuni dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 01:04 -------
Created an attachment (id=18276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18276&action=view)
Crash because gcc assumes false stack alignment

Here I'm submitting an example code that, when compiled with gcc 4.4.1 with -O3
-march=pentium3, crashes on Debian Lenny.

Don't close this bug unless this code is working! You can get it working either
by modifying gcc to align the stack (IMHO the easier way) or forcing all the
distributions to recompile all their binaries because you want to declare new
ABI (IMHO harder or impossible).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2009-07-31 07:12 -------
So, you found a glibc bug, which can be easily fixed by:
--- libc/malloc/Makefile 2009-05-16 19:23:36.000000000 +0200
+++ libc/malloc/Makefile 2009-07-31 09:09:51.760080072 +0200
@@ -104,6 +104,7 @@ $(objpfx)memusagestat: $(memusagestat-mo
 include ../Rules

 CFLAGS-mcheck-init.c = $(PIC-ccflag)
+CFLAGS-obstack.c = $(uses-callbacks)

 $(objpfx)libmcheck.a: $(objpfx)mcheck-init.o
 -rm -f $@

The deductions you make from it are wrong.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #14 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 13:54 -------
Jakub: And how many other "bugs" like this are there? 75% of binaries in /bin
are "buggy". Do you think it is really sensible to declare that majority of
Linux software is buggy?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #15 from hjl dot tools at gmail dot com  2009-07-31 14:27 -------
It is too late to change now. Even if we align the incoming
stack properly, we still have to align the outgoing stack
to 16byte since the existing binaries which use SSE won't
align the stack. That means we have to align the incoming
stack for all non-leaf functions.  Otherwise, we can't align
the outgoing stack. It is quite expensive.

The good news is we won't make the same mistake for AVX.
We now align the incoming stack as needed for AVX.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 15:22 -------
H.J. Lu: No, you only have to align the stack in functions that do 16-byte SSE.

I mean this:

there are two possible reasons for aligning the stack
1) improved performance (double, long double, MMX, 8-byte SSE)
2) avoid crashes (16-byte SSE)

To solve the case 1), it is perfectly reasonable to not align the stack and
simply make sure that every function subtracts the stack by multiple of
16-bytes. If, by chance, the code is called from some other code with unaligned
stack (like in that obstack example), the user will only suffer lower
performance, not crashes.

It is legal to make floating point calculations from obstack allocation
callback --- but it is not common. So we don't have to care about performance
in this case.

To solve the case 2), you need to manually realign the stack at function
prologue. But there are few functions that use SSE in typical desktop/server
environment, that's why I'm saying that it won't have big impact on
performance.

Anyway, if some scientist needs high 16-bit SSE performance, we can make a flag
for him that avoids stack realign --- but don't compile typical desktop/server
distribution with this flag, because there ARE cases where the stack is
misaligned.

That's what I'm proposing in comment #3: that every type has two alignments,
preferred alignment and enforced alignment. Only "enforced alignment" will
force stack realign.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #17 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 15:31 -------
"Even if we align the incoming stack properly, we still have to align the
outgoing stack to 16byte"

I'm not opposing it. What I mean is: every function will have stack frame size
that is multiple of mpreferred-stack-boundary (16 bytes) --- it is what GCC is
doing now. And additionally, there will be stack realign for functions that do
16-byte SSE math.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #18 from hjl dot tools at gmail dot com  2009-07-31 15:51 -------
(In reply to comment #17)
> "Even if we align the incoming stack properly, we still have to align the
> outgoing stack to 16byte"
> 
> I'm not opposing it. What I mean is: every function will have stack frame size
> that is multiple of mpreferred-stack-boundary (16 bytes) --- it is what GCC is
> doing now. And additionally, there will be stack realign for functions that do
> 16-byte SSE math.
> 

What you are looking for is an option to turn on force_align_arg_pointer
attribute for all functions which use 16byte SSE memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #19 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 16:17 -------
(In reply to comment #18)

Yes. But not an option. Make it default and make it optional to disable the
alignment. Make it default, because such option would be useless if all
libraries didn't use it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #20 from hjl dot tools at gmail dot com  2009-08-06 16:48 -------
(In reply to comment #19)
> (In reply to comment #18)
> 
> Yes. But not an option. Make it default and make it optional to disable the
> alignment. Make it default, because such option would be useless if all
> libraries didn't use it.
> 

It isn't a bad idea. See PR 32893/40985.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |32893
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #21 from hjl dot tools at gmail dot com  2009-08-06 21:05 -------
Created an attachment (id=18314)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18314&action=view)
A patch

Here is a patch to automatically realign stack if any SSE variable
is put on stack.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #22 from hjl dot tools at gmail dot com  2009-08-06 21:43 -------
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00392.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2009-
                   |                            |08/msg00392.html
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-06 21:43:34
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-08-08 17:30 -------
(In reply to comment #21)

Unfortunatelly, that patch is wrong. It aligns when there is some vector type
in the function but it doesn't align if the autovectorizer creates SSE
instructions. Try that obstack example in comment #12 and you see that the
function my_alloc uses 16-byte sse instructions on stack and it doesn't have
aligned stack with the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #24 from hjl dot tools at gmail dot com  2009-08-16 17:37 -------
(In reply to comment #23)
> (In reply to comment #21)
> 
> Unfortunatelly, that patch is wrong. It aligns when there is some vector type
> in the function but it doesn't align if the autovectorizer creates SSE
> instructions. Try that obstack example in comment #12 and you see that the
> function my_alloc uses 16-byte sse instructions on stack and it doesn't have
> aligned stack with the patch.
>

I got

my_alloc:
        pushl   %ebp
        movl    $.LC0, %edx
        movl    %esp, %ebp
        andl    $-16, %esp
        pushl   %ebx

It looks OK to me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #25 from hjl dot tools at gmail dot com  2009-08-18 04:43 -------
Created an attachment (id=18393)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18393&action=view)
A patch for gcc 4.4


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #26 from hjl dot tools at gmail dot com  2009-08-18 04:50 -------
*** Bug 40985 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mahatma at eu dot by


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

------- 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=18393&action=view) [edit]
> A patch for gcc 4.4

Are this patch may conflict with your patch?
http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340&action=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 rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #28 from hjl dot tools at gmail dot com  2009-08-18 14:01 -------
(In reply to comment #27)
> (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=18393&action=view) [edit]
> > A patch for gcc 4.4
> 
> Are this patch may conflict with your patch?
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340&action=vie

This is not mine and isn't needed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

------- 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

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #30 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-08-23 19:28 -------
I tested the 4.4 patch and it works fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

------- 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 rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #32 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-13 13:58 -------
Created an attachment (id=18578)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578&action=view)
A bug example for 4.4 patch

Shows a bug in 4.4 patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #33 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-13 13:59 -------
Created an attachment (id=18579)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579&action=view)
Another bug in 4.4 patch

Another bug in 4.4 patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #34 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-13 14:07 -------
So I posted these two examples that show that the patch is insufficient:

1) if the array is embedded in a structure and that structure is on the stack,
the stack is not aligned. (if the array were out of structure, it would be)

2) gcc sometimes spills xmm registers over function calls (spilling zero this
way is suboptimal, but that's only a performance issue) and the stack is not
aligned in this case.

Note, in align-counterexample2.c, there is another bug! Gcc shouldn't assume
that arrays "x" and "y" are 16-byte aligned. Arrays "x" and "y" are in common
section, that means that they can be declared in any other module and the
linker joins these declarations. So, for example, if in another module someone
declared int x[100] = { 1, 2, 3, 4 } and the module were compiled with
different compiler that doesn't align the array (the ABI allows it) , the
linker is forced to use the declaration with the initialization and the array
would be misaligned.

We can only assume alignment on the variables that are not in common section,
i.e. with -fno-common or explicitly initialized.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #35 from hjl dot tools at gmail dot com  2009-09-19 21:37 -------
Created an attachment (id=18610)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18610&action=view)
An updated patch for gcc 4.4


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18393|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #36 from hjl dot tools at gmail dot com  2009-09-19 21:38 -------
Created an attachment (id=18611)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18611&action=view)
An updated patch for gcc trunk


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18314|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #37 from hjl dot tools at gmail dot com  2009-09-19 21:38 -------
(In reply to comment #33)
> Created an attachment (id=18579)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579&action=view) [edit]
> Another bug in 4.4 patch
> 
> Another bug in 4.4 patch.
> 

This one doesn't need stack alignment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #38 from hjl dot tools at gmail dot com  2009-09-19 21:40 -------
(In reply to comment #32)
> Created an attachment (id=18578)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578&action=view) [edit]
> A bug example for 4.4 patch
> 
> Shows a bug in 4.4 patch
> 

Please try the updated patch in comment #35


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #39 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-20 06:30 -------
The updated patch fixes align-counterexample1.c, but not
align-counterexample2.c. Note that you must align the stack for all functions
that have some SSE operations, because you never know if the registers will be
spilled. The generated code is:

.globl f
        .type   f, @function
f:
        pxor    %xmm0, %xmm0
        subl    $28, %esp
        xorl    %eax, %eax
        .p2align 5,,24
.L2:
        movaps  %xmm0, p(%eax)
        addl    $16, %eax
        cmpl    $400, %eax
        jne     .L2
        movaps  %xmm0, (%esp)
        call    g
        movdqa  (%esp), %xmm0
        xorl    %eax, %eax
        .p2align 5,,24
.L3:
        movaps  %xmm0, q(%eax)
        addl    $16, %eax
        cmpl    $400, %eax
        jne     .L3
        addl    $28, %esp
        ret


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #40 from hjl dot tools at gmail dot com  2009-09-20 18:43 -------
Created an attachment (id=18617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18617&action=view)
An updated patch for gcc trunk


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18611|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #41 from hjl dot tools at gmail dot com  2009-09-20 18:44 -------
Created an attachment (id=18618)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18618&action=view)
An updated patch for gcc 4.4


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18610|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #42 from hjl dot tools at gmail dot com  2009-09-20 18:44 -------
(In reply to comment #39)
> The updated patch fixes align-counterexample1.c, but not
> align-counterexample2.c. Note that you must align the stack for all functions
> that have some SSE operations, because you never know if the registers will be
> spilled. The generated code is:
> 

Please try the new patch in comment #41.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #43 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-23 16:28 -------
With the patch from comment #41, my test examples pass but seamonkey is still
miscompiled, the function pow5mult still doesn't align the stack and spills
xmm0 on it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #44 from hjl dot tools at gmail dot com  2009-09-23 16:34 -------
(In reply to comment #43)
> With the patch from comment #41, my test examples pass but seamonkey is still
> miscompiled, the function pow5mult still doesn't align the stack and spills
> xmm0 on it.
> 

Please find a testcase. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

------- 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=18618&action=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 rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #46 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-25 00:56 -------
Created an attachment (id=18646)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18646&action=view)
A patch for gcc 4.4.1

I decided to make a patch on my own. Seamonkey works with it. It sometimes
aligns unnecessarily but it should never miss an alignment. (someone with more
knowledge about gcc than me could refine the patch to make fewer unneeded
alignments) I searching the generated seamonkey code for 'movaps.*esp' and it
shows that all the functions that store xmm on the stack use stack alignment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #47 from hjl dot tools at gmail dot com  2009-09-25 02:31 -------
(In reply to comment #46)
> Created an attachment (id=18646)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18646&action=view) [edit]
> A patch for gcc 4.4.1
> 
> I decided to make a patch on my own. Seamonkey works with it. It sometimes
> aligns unnecessarily but it should never miss an alignment. (someone with more
> knowledge about gcc than me could refine the patch to make fewer unneeded
> alignments) I searching the generated seamonkey code for 'movaps.*esp' and it
> shows that all the functions that store xmm on the stack use stack alignment.
> 

You can find a testcase as the first step.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #48 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-26 04:25 -------
It can be seen from the patch. I don't know how to detect that a structure
contains an array with required SSE align, so I realign the stack for all types
BLKmode with alignment >= 16. That may also catch structures containing long
double with -m128bit-long-double and do unneeded align for them.

Another point where it aligns and doesn't have to is: there are some SSE
variables used --- that trigger frame generation to prepare for a possible
align --- after register allocation, they are not spilled, so the alignment is
not needed --- but there are some other aligned types on the stack (for example
floating point; they do not need enforced alignment). Then, my patch simply
realigns the stack.

I think the patch is a good hack that may be added to 4.4 so that Gentoo people
stop whining that gcc -O3 is unstable. But for 4.5, the stack realign needs to
be redesigned. There are other cases ( PR/40667 ) where it triggers stack
alignment that is not needed. As I said in comment #3: introduce preferred and
enforced alignment for all types will do the right thing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #49 from hjl dot tools at gmail dot com  2009-09-26 14:06 -------
(In reply to comment #48)
> It can be seen from the patch. I don't know how to detect that a structure
> contains an array with required SSE align, so I realign the stack for all types

Please find a testcase first. Otherwise, nothing will be done. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #50 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-26 15:44 -------
> Please find a testcase first. Otherwise, nothing will be done. Thanks.

I don't want anything to be done (unless the patch causes generation of wrong
code --- I am not aware of such case).

I am saying that the patch could be included in 4.4 as a quick fix and that 4.5
needs stack alignment redesign. You can't redesign it by incrementally testing
against a set of examples. You (or someone else) need to sit down, draft the
rules for propagation of preferred and enforced alignment across types down to
the stack frame and code it. If you understand what you're doing, you can
create test examples on your own. If you don't understand, then don't hack it
at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #51 from hjl dot tools at gmail dot com  2009-09-26 16:15 -------
(In reply to comment #50)
> 
> I am saying that the patch could be included in 4.4 as a quick fix and that 4.5
> needs stack alignment redesign. You can't redesign it by incrementally testing
> against a set of examples. You (or someone else) need to sit down, draft the
> rules for propagation of preferred and enforced alignment across types down to
> the stack frame and code it. If you understand what you're doing, you can
> create test examples on your own. If you don't understand, then don't hack it
> at all.
>

The stack realignment works correctly as designed. The problems come from

1. Gcc generates code for 16byte-aligned incoming stack.
2. Gcc generates 16byte-aligned outgoing stack.
3. SSE variables segfault if they aren't 16byte aligned.
4. Some incoming stacks aren't aligned at 16byte, which violates #1 and
may cause #3.

We have to do #2 since many existing binaries need 16byte-aligned
incoming stack. If we assume incoming stack is 4byte aligned, we
have to realign stack for every function due to #2, which isn't
acceptable. To accommodate #4, which isn't strictly required, and
avoid #3 with minimum stack realignment, we need to list all #4
cases which lead to #3. Then we can investigate how to address them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #52 from hjl dot tools at gmail dot com  2009-09-26 16:55 -------
Created an attachment (id=18655)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18655&action=view)
An updated patch for gcc 4.4

Please try this patch for gcc 4.4.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18618|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #53 from hjl dot tools at gmail dot com  2009-09-26 16:58 -------
Created an attachment (id=18656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656&action=view)
An updated patch for gcc 4.4

Oops. Wrong patch.  Trry this one.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18655|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #54 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-27 09:03 -------
(In reply to comment #51)

For 4.4, the designers held two wrong assumptions:

1) the incoming stack is always aligned on -mincoming-stack-boundary (wrong for
functions called from assembler or code generated by other compilers).

2) all the variables must be aligned on their alignment (wrong for double, long
double, long long, mmx: the processor may accept them misaligned).

The assumption 1) generates crashing code (for example Seamonkey). The
assumption 2) generates suboptimal code (bug #40667).

The assumption 1) can be trivially quashed with parameter
-mincoming-stack-boundary=2, then the code will be non-crashing, but you will
be hitting problem 2) and the code will be ugly and slow: any function
containing double or long double variable will generate code for stack
realigning and a frame pointer. (for long long this inefficiency was partially
fixed in 4.4.1, but only partially, single long long variables don't trigger
the alignment after 4.4.1 but structures with long long do, see bug #40667).

So: to fix problem 1), gcc should assume that the incoming stack is 4-byte
aligned. To fix problem 2), instead of single alignment, types and variables
should have two alignments: preferred alignment and enforced alignment (so that
you don't realign the stack if there is double on it, but you realign it if
there is 16-byte SSE).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #55 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-27 09:07 -------
"If we assume incoming stack is 4byte aligned, we have to realign stack for
every function due to #2, which isn't acceptable."

No, you don't. All you have to do is to allocate the stack frame that is
multiple of 16 bytes (gcc does that already).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #56 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-27 09:36 -------
As for this "old code that assumes 16-byte alignment": this is wrong code
generated by old versions of gcc. It only works as long as it is called from
other gcc >= 3 code (call it from gcc < 3, icc or assembler and it crashes). So
you don't have to realign the stack to make sure that the code works always (it
doesn't, anyway). All you have to do with this old code is to make sure that
you don't make things worse --- i.e. if it worked before, it should continue
work after redesign. So all you need is to make a stack frame having a multiple
of 16-bytes. No realign needed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

------- 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=18656&action=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 rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #58 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-10-15 20:24 -------
(In reply to comment #53)
> Created an attachment (id=18656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656&action=view) [edit]
> An updated patch for gcc 4.4

Seamonkey is correct with that patch. But it fails with structures containing
sse vector, i.e. this. My patch (in comment #46) handles this case correctly
(it reallign the stack if any structure on it has alignment at least 16), so
should we submit that patch instead?

I think it's wrong to add alignment test to the autovectorizer because vector
data types can be created explicitly without autovectorizer.

Mikulas


typedef int v4si __attribute__ ((vector_size (16)));

struct x {
        v4si v;
        v4si w;
};

void y(void *);

v4si x(void)
{
        struct x x;
        y(&x);
}

--- the function "x" should realign the stack but doesn't.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #59 from hjl dot tools at gmail dot com  2009-10-15 20:54 -------
(In reply to comment #58)
> (In reply to comment #53)
> > Created an attachment (id=18656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656&action=view) [edit]
> > An updated patch for gcc 4.4
> 
> Seamonkey is correct with that patch. But it fails with structures containing
> sse vector, i.e. this. My patch (in comment #46) handles this case correctly
> (it reallign the stack if any structure on it has alignment at least 16), so
> should we submit that patch instead?
> 
> I think it's wrong to add alignment test to the autovectorizer because vector
> data types can be created explicitly without autovectorizer.
> 
> Mikulas
> 
> 
> typedef int v4si __attribute__ ((vector_size (16)));
> 
> struct x {
>         v4si v;
>         v4si w;
> };
> 
> void y(void *);
> 
> v4si x(void)
> {
>         struct x x;
>         y(&x);
> }
> 

Why should gcc align the stack when SSE registers aren't used
at all?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #60 from hjl dot tools at gmail dot com  2009-10-16 00:56 -------
Created an attachment (id=18805)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18805&action=view)
An updated patch

This patch aligns stack if there is a stack variable with 128bit alignment.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18656|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #61 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-10-16 02:10 -------
> Why should gcc align the stack when SSE registers aren't used
> at all?

Because it passes pointer to the structure containing vector entries to someone
else who expects it to be aligned.

As for the updated patch --- why does it modify the autovectorizer? Anything
that the autovectorizer does can be done manually without the autovectorizer.
So, if there is a case where patching the autovectorizer is required to avoid a
bug, there is definitely another case, where the bug still persists if the
programmer vectorizes the code explicitly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #62 from hjl dot tools at gmail dot com  2009-10-16 02:48 -------
(In reply to comment #61)
> 
> As for the updated patch --- why does it modify the autovectorizer? Anything
> that the autovectorizer does can be done manually without the autovectorizer.
> So, if there is a case where patching the autovectorizer is required to avoid a
> bug, there is definitely another case, where the bug still persists if the
> programmer vectorizes the code explicitly.

Show me the testcase. When you create a vector variable on stack,
the hard stack alignment will be updated. Vectorizer may not alwats
put vector variable on stack. That is why I have to track it separately.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl at gcc dot gnu dot org]

------- Comment #63 from hjl at gcc dot gnu dot org  2009-10-30 14:32 -------
Subject: Bug 40838

Author: hjl
Date: Fri Oct 30 14:32:26 2009
New Revision: 153750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153750
Log:
Optimize -mstackrealign.

gcc/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40836
        * cfgexpand.c (expand_stack_alignment): Call update_stack_boundary
        first.  Move assert on stack_alignment_estimated just before
        setting stack_realign_needed.
        (gimple_expand_cfg): Initialize stack_alignment_estimated to 0.
        Don't call update_stack_boundary.

        * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): New.
        (verride_options): Don't check ix86_force_align_arg_pointer here.
        (ix86_function_ok_for_sibcall): Use it.
        (ix86_update_stack_boundary): Likewise.

        * config/i386/i386.h (STACK_REALIGN_DEFAULT): Update comments.

gcc/testsuite/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40838
        * gcc.target/i386/incoming-6.c: New.
        * gcc.target/i386/incoming-7.c: Likewise.
        * gcc.target/i386/incoming-8.c: Likewise.
        * gcc.target/i386/incoming-9.c: Likewise.
        * gcc.target/i386/incoming-10.c: Likewise.
        * gcc.target/i386/incoming-11.c: Likewise.
        * gcc.target/i386/incoming-12.c: Likewise.
        * gcc.target/i386/incoming-13.c: Likewise.
        * gcc.target/i386/incoming-14.c: Likewise.
        * gcc.target/i386/incoming-15.c: Likewise.
        * gcc.target/i386/pr37843-4.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.target/i386/incoming-10.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-11.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-12.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-13.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-14.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-15.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-6.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-7.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-8.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-9.c
    trunk/gcc/testsuite/gcc.target/i386/pr37843-4.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/i386.h
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl at gcc dot gnu dot org]

------- Comment #64 from hjl at gcc dot gnu dot org  2009-10-30 15:45 -------
Subject: Bug 40838

Author: hjl
Date: Fri Oct 30 15:45:23 2009
New Revision: 153757

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153757
Log:
gcc/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40838
        * cfgexpand.c (expand_stack_alignment): Call update_stack_boundary
        first.  Move assert on stack_alignment_estimated just before
        setting stack_realign_needed.
        (gimple_expand_cfg): Initialize stack_alignment_estimated to 0.
        Don't call update_stack_boundary.

        * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): New.
        (verride_options): Don't check ix86_force_align_arg_pointer here.
        (ix86_function_ok_for_sibcall): Use it.
        (ix86_update_stack_boundary): Likewise.

        * config/i386/i386.h (STACK_REALIGN_DEFAULT): Update comments.

gcc/testsuite/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40838
        * gcc.target/i386/incoming-6.c: New.
        * gcc.target/i386/incoming-7.c: Likewise.
        * gcc.target/i386/incoming-8.c: Likewise.
        * gcc.target/i386/incoming-9.c: Likewise.
        * gcc.target/i386/incoming-10.c: Likewise.
        * gcc.target/i386/incoming-11.c: Likewise.
        * gcc.target/i386/incoming-12.c: Likewise.
        * gcc.target/i386/incoming-13.c: Likewise.
        * gcc.target/i386/incoming-14.c: Likewise.
        * gcc.target/i386/incoming-15.c: Likewise.
        * gcc.target/i386/pr37843-4.c: Likewise.

Added:
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-10.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-11.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-12.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-13.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-14.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-15.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-6.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-7.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-8.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/incoming-9.c
    branches/ix86/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr37843-4.c
Modified:
    branches/ix86/gcc-4_4-branch/gcc/ChangeLog.ix86
    branches/ix86/gcc-4_4-branch/gcc/cfgexpand.c
    branches/ix86/gcc-4_4-branch/gcc/config/i386/i386.c
    branches/ix86/gcc-4_4-branch/gcc/config/i386/i386.h
    branches/ix86/gcc-4_4-branch/gcc/testsuite/ChangeLog.ix86


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #65 from hjl dot tools at gmail dot com  2009-10-31 16:47 -------
Here are the differences of "-m32 -O3 -msse2 -mfpmath=sse -ffast-math
-funroll-loops" vs. "-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops
-mstackrealign" using ix86/gcc-4_4-branch on Intel Core i7:

164.gzip                         -0.604595%
175.vpr                          -0.0831255%
176.gcc                          -0.567698%
181.mcf                          0.142653%
186.crafty                       0.0783699%
197.parser                       -0.355714%
252.eon                          -2.32775%
253.perlbmk                      0.943693%
254.gap                          0.553825%
255.vortex                       0.226978%
256.bzip2                        0.291971%
300.twolf                        0.183936%
SPECint_base2000                 -0.126734%
168.wupwise                      -0.345871%
171.swim                         -1.42753%
172.mgrid                        0.496166%
173.applu                        0.467758%
177.mesa                         0.151791%
178.galgel                       -0.227652%
179.art                          0.338073%
183.equake                       -0.308569%
187.facerec                      0.189798%
188.ammp                         1.00536%
189.lucas                        -2.18097%
191.fma3d                        -1.0162%
200.sixtrack                     0.237906%
301.apsi                         1.00138%
SPECfp_base2000                 -0.121114%
400.perlbench                    0.4%
401.bzip2                        0%
403.gcc                          0%
429.mcf                          0%
445.gobmk                        -0.478469%
456.hmmer                        0%
458.sjeng                        0.452489%
462.libquantum                   -0.689655%
464.h264ref                      -0.331126%
471.omnetpp                      0.483092%
473.astar                        0.666667%
483.xalancbmk                    -0.358423%
SPECint(R)_base2006              0%
410.bwaves                       11.2108%
416.gamess                       -0.543478%
433.milc                         1.37615%
434.zeusmp                       -0.497512%
435.gromacs                      0%
436.cactusADM                    -0.763359%
437.leslie3d                     0.625%
444.namd                         0%
447.dealII                       -0.689655%
450.soplex                       -1.2987%
453.povray                       -0.904977%
454.calculix                     0.621118%
459.GemsFDTD                     -0.625%
465.tonto                        0%
470.lbm                          0.925926%
481.wrf                          -0.588235%
482.sphinx3                      -0.96463%
SPECfp(R)_base2006               0%


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

------- Comment #66 from hjl dot tools at gmail dot com  2009-12-26 22:19 -------
*** Bug 42513 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mecareful at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[t dot artem at mailcity dot com]

------- Comment #67 from t dot artem at mailcity dot com  2010-04-17 14:28 -------
Am I right assuming that GCC 4.5 is also affected by this bug? Is this bug
going to be resolved?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #68 from mikulas at artax dot karlin dot mff dot cuni dot cz  2010-04-20 07:48 -------
gcc 4.5 is affected too. It would be nice if they fixed it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[t dot artem at mailcity dot com]

------- Comment #69 from t dot artem at mailcity dot com  2010-04-29 02:12 -------
(In reply to comment #64)
> Subject: Bug 40838
> 

This patch is not sufficient, some applications still crash after I've applied
it to GCC 4.4 branch (to be more precise gcc-4.4-20100427.tar.bz2).

I still wonder how GCC 4.4.x and 4.5.0 were ever released, to me it's a zero
priority bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[ubizjak at gmail dot com]

------- Comment #70 from ubizjak at gmail dot com  2010-04-29 06:29 -------
(In reply to comment #69)
> (In reply to comment #64)
> > Subject: Bug 40838
> > 
> 
> This patch is not sufficient, some applications still crash after I've applied
> it to GCC 4.4 branch (to be more precise gcc-4.4-20100427.tar.bz2).

You did use -mstackrealign?

> I still wonder how GCC 4.4.x and 4.5.0 were ever released, to me it's a zero
> priority bug.

So, export CFLAGS="-mstackrealign"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[t dot artem at mailcity dot com]

------- Comment #71 from t dot artem at mailcity dot com  2010-04-29 07:24 -------
(In reply to comment #70)

No, I haven't used -mstackrealign as I presumed that the patch is sufficient -
and since you make me sound like I'm wrong, then the patch is also wrong, since
GCC must be producing a working code with no extra compilation flags.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

------- Comment #72 from jakub at gcc dot gnu dot org  2010-04-29 07:33 -------
There is no agreement on this being actually a bug, -mpreferred-stack-boundary
is actually an ABI changing option and if you use it you are supposed to deal
with the things it is causing (such as using -mstackrealign when calling code
between the different ABIs).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[ubizjak at gmail dot com]

------- Comment #73 from ubizjak at gmail dot com  2010-04-29 07:50 -------
>From the manual:

`-mstackrealign'
     Realign the stack at entry.  On the Intel x86, the `-mstackrealign'
     option will generate an alternate prologue and epilogue that
     realigns the runtime stack if necessary.  This supports mixing
     legacy codes that keep a 4-byte aligned stack with modern codes
     that keep a 16-byte stack for SSE compatibility.  See also the
     attribute `force_align_arg_pointer', applicable to individual
     functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[t dot artem at mailcity dot com]

------- Comment #74 from t dot artem at mailcity dot com  2010-04-29 08:29 -------
Guys, you are talking in riddles.

There's a fact: with -msse2 -O2 -m32 flags GCC generate bad code for some
properly coded applications, so I wonder what users are supposed to do.

There are already six duplicates of this bug in Wine's bugzilla and several
duplicates in Gentoo bugzilla.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[dirtyepic at gentoo dot org]

------- Comment #75 from dirtyepic at gentoo dot org  2010-04-29 22:58 -------
if some libraries, (zlib and fontconfig i've had personal experience with, i've
also heard libgcrypt) are compiled with -ftree-vectorize (ie. -O3) on x86
systems supporting SSE2, it causes segfaults in certain packages, usually
mozilla-based or wine, when SSE2 instructions requiring 16bit alignment are
used on unaligned data.  nothing is being built with -mpreferred-stack-boundary
in these cases. this is PR41156, https://bugzilla.redhat.com/489290,
https://bugs.gentoo.org/270120.  i'm not convinced this is GCC's problem.  it
usually gets traced back as far as something in the mozilla codebase
misaligning the stack at which point everyone seems to give up.  i've yet to
see an actual testcase, though I've encountered it several times in the wild.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jcea at hispasec dot com]

------- Comment #76 from jcea at hispasec dot com  2010-05-12 13:00 -------
[Zlib-devel] HEADS UP: Apparent bad compilation under (just released) GCC 4.5.0

http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002267.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jcea at hispasec dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 227 bytes --]



------- Comment #77 from jcea at hispasec dot com  2010-05-12 13:14 -------
Discussión in progress:
http://mail.python.org/pipermail/python-dev/2010-May/100044.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jasmin at revisionfx dot com]

------- Comment #78 from jasmin at revisionfx dot com  2010-08-09 01:56 -------

I am not exactly sure how to report a bug here - but it seems highly related to
this thread (I am pierre@revisionfx.com, since I am not sure if I am
auto-subscribed to this thread, and so will get email back about this)

It appears (whatever the version) that this construct in 32b linux (below) does
not work after -shared (ld...) - does not work means is not aligned anymore to
16 bytes/128 bits boundary. If I compile a library with such code, and link it
as in an executable, it seems to work but if I do it as shared object the
alignment is not guaranteed anymore. Anyone has an idea about what to do, if
this will be addressed... or GNU just assumes 32b will go away? Or the problem
is different.  All this works fine with Mac OSX gcc -m32 compile by the way.

Also, if I compile with Intel CC does that fix the problem for an host that is
Intel CC compiled? (As in is it possible that mixed compiler context - host
versus dynamic library further cause complications).

#define MAX_CONV_KERNEL_SIZE                    4096
class ConvKernel4f  
{
        public:

                ConvKernel4f ( );
                ~ConvKernel4f( );
                DATA_ALIGN(float4       mFilterPtr[MAX_CONV_KERNEL_SIZE]);

};


-- 

jasmin at revisionfx dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasmin at revisionfx dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jasmin at revisionfx dot com]

------- Comment #79 from jasmin at revisionfx dot com  2010-08-11 21:26 -------
 > I am not exactly sure how to report a bug here  

Find the answer here:

https://bugs.launchpad.net/sbcl/+bug/539632

" Compile with -mpreferred-stack-boundary=2. This will force GCC to compile
code that adheres to the ABI and therefore properly adjusts its own stack
pointer."

that works


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #80 from mikulas at artax dot karlin dot mff dot cuni dot cz  2010-08-17 20:17 -------
Comment #79:

-mpreferred-stack-boundary=2 adheres to the sysv ABI but it doesn't adhere to
the Linux ABI (that requires 16-byte alignment), so if you compile anything
with -mpreferred-stack-boundary=2, it may crash when entering other dynamic
libraries.

-mstackrealign does the right thing, it realigns the stack when needed, but
keeps it 16-byte aligned on function output. It should be used.

I would be nice if gcc developers made -mstackrealign default (with an option
to turn it off for scientists who need maximum performance and don't care about
ABI) so that this ABI madness will finally end when distributions get
recompiled with it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jasmin at revisionfx dot com]

------- Comment #81 from jasmin at revisionfx dot com  2010-08-17 21:03 -------
(In reply to comment #80)
> Comment #79:
> 

> -mstackrealign does the right thing, it realigns the stack when needed, but
> keeps it 16-byte aligned on function output. It should be used.
>  

I don't have that option (-mstackrealign)
It's available in gcc linux from what released version?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #82 from mikulas at artax dot karlin dot mff dot cuni dot cz  2010-08-17 21:17 -------
-mstackrealign is available from gcc 4.5.0. For gcc 4.4 you can use my patch
GCC-4.4.1-ALIGN-PATCH from this bugzilla or H.J.Lu's last patch. It basically
does the same as -mstackrealign (but it doesn't add a command line option, it
sets this behavior as default).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jasmin at revisionfx dot com]

------- Comment #83 from jasmin at revisionfx dot com  2010-08-24 22:09 -------
(In reply to comment #82)
> -mstackrealign is available from gcc 4.5.0. 

So 1) you are right that somehow - mpreferred-stack-boundary=2 does not always
work - I found a case where I crash 
2) so I compiled gcc 4.5.1 and recompiled and same (with or without
-mstackrealign) 
I am noting there might be a new bug. When (I am a shared library) I call back
the host(an exec I run in as a plugin) to check abort I now have a problem with
throw.  My throw is in a try/catch but somehow seems going into host space by
calling it back makes the throw pass through and the host terminates / abort as
it gets a throw it does not know anything about. 
-- I am not equiped right now to test more 32b linux gcc as I don't have a
proper host side way of testing this right now. Just raising a flag.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #84 from mikulas at artax dot karlin dot mff dot cuni dot cz  2010-08-25 21:27 -------
(In reply to comment #83)

If the bug is not related to stack alignment (i.e. it crashes not on unaligned
SSE access), simplify it and file another bugzilla entry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[t.artem at mailcity dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

--- Comment #85 from Artem S. Tashkinov <t.artem at mailcity dot com> 2011-01-18 21:02:43 UTC ---
Am I the only one who thinks this bug should be nominated as the first priority
GCC 4.6.0 bug?

I don't really care if the fix would be backported to 4.5.x or 4.4.x releases,
but at least it would be better to have it fixed for GCC 4.6.0.

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

--- Comment #86 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-18 21:07:26 UTC ---
I am in the process of updating i386 psABI to specify 16byte stack
alignment.

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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 rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #88 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Marked for reference. Resolved as fixed @bugzilla.