public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
@ 2002-10-10 11:13 hubicka
0 siblings, 0 replies; 4+ messages in thread
From: hubicka @ 2002-10-10 11:13 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, ryants
Synopsis: __attribute__((aligned(16))) seems to be ignored on x86
State-Changed-From-To: open->closed
State-Changed-By: hubicka
State-Changed-When: Thu Oct 10 11:13:35 2002
State-Changed-Why:
This is runtime problem that missaligns stack frame of function main. You need to update to runtime compiled with gcc 3.0+ or not use aligned data in the function main (gcc aligns outgoing frame so the called functions will be aligned properly)
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3299
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
@ 2002-10-11 7:26 Jan Hubicka
0 siblings, 0 replies; 4+ messages in thread
From: Jan Hubicka @ 2002-10-11 7:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/3299; it has been noted by GNATS.
From: Jan Hubicka <jh@suse.cz>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: hubicka@gcc.gnu.org, gcc-bugs@gcc.gnu.org, ryants@home.com,
gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
Date: Fri, 11 Oct 2002 16:17:58 +0200
> hubicka@gcc.gnu.org writes:
>
> | Synopsis: __attribute__((aligned(16))) seems to be ignored on x86
> |
> | State-Changed-From-To: open->closed
> | State-Changed-By: hubicka
> | State-Changed-When: Thu Oct 10 11:13:35 2002
> | State-Changed-Why:
> | This is runtime problem that missaligns stack frame of function main. You need to update to runtime compiled with gcc 3.0+ or not use aligned data in the function main (gcc aligns outgoing frame so the called functions will be aligned properly)
>
> Jan,
>
> Please could you add a note to that effect in the documentation?
> Thanks,
Good idea. I was thinking about adding it to FAQ too. Here is my
attempt for the description. WOuld you mind to correct it?
Fri Oct 11 16:15:51 CEST 2002 Jan Hubicka <jh@suse.cz>
* extend.texi (SSE vector operations and stack alignment): New subsection.
Index: extend.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/doc/extend.texi,v
retrieving revision 1.106
diff -c -3 -p -r1.106 extend.texi
*** extend.texi 11 Oct 2002 04:15:14 -0000 1.106
--- extend.texi 11 Oct 2002 14:15:33 -0000
*************** v2sf __builtin_ia32_pswapdsf (v2sf)
*** 5241,5246 ****
--- 5241,5277 ----
v2si __builtin_ia32_pswapdsi (v2si)
@end example
+ @subsection SSE vector operations and stack alignment
+
+ Unlike other i386 instructions, SSE operations often strictly require the
+ memory operands to be 16 byte aligned. When this restriction is not met, program
+ crash.
+
+ In order to avoid crash, all data structures accessed by SSE operations needs
+ to be properly aligned. It is common mistake, for instance, to access array of
+ 4 floats directly by single SSE operation. In order to get this working,
+ attribute @code{alignment} needs to be used.
+
+ Another common case is situation, where compiler spills SSE register into stack
+ frame that is not itself properly aligned. Unfortunately the Application
+ Binary Interface mandates only 4 byte alignment of stack frames and thus it is
+ never safe to spill register without precautions. GCC makes this possible by
+ keeping stack pointer aligned to 16 byte boundary at each function call (see
+ @code{-mpreffered-stack-boundary} for details), however this scheme can break
+ when code compiled with lower stack pointer alignment restrictions is used to
+ call code with higher ones. This may be the case of call-backs called from
+ library compiled using different compiler or runtime not aligning properly
+ stack pointer when invoking @code{main()}. Unfortunately GCC 2.95 did contain
+ bug that miss-compiled startup code of glibc and some other libraries to
+ misalign stack. To avoid problems with on such systems, GCC automatically
+ instrument function @code{main()} to align outgoing stack pointer dynamically.
+ This makes stack frame of all functions called from @code{main()} to be
+ properly aligned, however it does not align the frame of @code{main*(} itself.
+
+ In short when your runtime is not 16 byte alignment safe, it is impossible to
+ use SSE inside the function @code{main()}, any other function inlined to it, or
+ any function called via some kind of call-back from library code.
+
@node PowerPC AltiVec Built-in Functions
@subsection PowerPC AltiVec Built-in Functions
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
@ 2002-10-10 12:06 Gabriel Dos Reis
0 siblings, 0 replies; 4+ messages in thread
From: Gabriel Dos Reis @ 2002-10-10 12:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/3299; it has been noted by GNATS.
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: hubicka@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, ryants@home.com, gcc-gnats@gcc.gnu.org
Subject: Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
Date: 10 Oct 2002 20:56:47 +0200
hubicka@gcc.gnu.org writes:
| Synopsis: __attribute__((aligned(16))) seems to be ignored on x86
|
| State-Changed-From-To: open->closed
| State-Changed-By: hubicka
| State-Changed-When: Thu Oct 10 11:13:35 2002
| State-Changed-Why:
| This is runtime problem that missaligns stack frame of function main. You need to update to runtime compiled with gcc 3.0+ or not use aligned data in the function main (gcc aligns outgoing frame so the called functions will be aligned properly)
Jan,
Please could you add a note to that effect in the documentation?
Thanks,
-- Gaby
^ permalink raw reply [flat|nested] 4+ messages in thread
* c++/3299: __attribute__((aligned(16))) seems to be ignored on x86
@ 2001-06-20 10:56 ryants
0 siblings, 0 replies; 4+ messages in thread
From: ryants @ 2001-06-20 10:56 UTC (permalink / raw)
To: gcc-gnats
>Number: 3299
>Category: c++
>Synopsis: __attribute__((aligned(16))) seems to be ignored on x86
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jun 20 10:56:03 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Ryan T. Sammartino
>Release: gcc version 2.95.3 19991030 (prerelease)
>Organization:
>Environment:
Linux 2.4.5-6mdksmp #1 SMP Mon Jun 18 10:19:22 PDT 2001 i686 unknown
>Description:
The following code (which doesn't include anything, so it's the same as the .ii that is generated) seg faults because none of v1, v2, or ret are aligned to a 16 byte boundary, as required for the movaps instruction:
---cut here---
class vector
{
public:
float x;
float y;
float z;
float w;
vector(float _x, float _y, float _z, float _w)
: x(_x), y(_y), z(_z), w(_w)
{}
vector()
{}
vector operator+(const vector &v1)
{
vector ret __attribute__((aligned(16)));
asm("movl %1, %%esi \n"
"movl %2, %%edi \n"
"movaps (%%esi), %%xmm0 \n"
"addps (%%edi), %%xmm0 \n"
"movaps %%xmm0, %0 \n"
: "=g" (ret) : "r" (this), "r" (&v1));
return ret;
}
} __attribute__((aligned(16)));
int main(int argc, char *argv[])
{
vector v1(3.0f, 4.0f, 5.0f, 1.0f);
vector v2(7.0f, 1.0f, 9.0f, 1.0f);
vector ans = v1 + v2;
}
---cut here---
Here is the output I get:
$ g++ -v -save-temps -Wall -g sse.cpp -o sse
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di586 -Dpentium -D__i586 -D__i586__ -D__pentium -D__pentium__ sse.cpp sse.ii
GNU CPP version 2.95.3 19991030 (prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/../../../../include/g++-3
/usr/local/include
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/../../../../i586-mandrake-linux/include
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/cc1plus sse.ii -quiet -dumpbase sse.cc -g -Wall -version -o sse.s
GNU C++ version 2.95.3 19991030 (prerelease) (i586-mandrake-linux) compiled by GNU C version 2.95.3 19991030 (prerelease).
sse.cpp: In function `int main(int, char **)':
sse.cpp:36: warning: unused variable `class vector ans'
as -V -Qy -o sse.o sse.s
GNU assembler version 2.10.91 (i686-mandrake-linux) using BFD version 2.10.91.0.2
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o sse /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/crtbegin.o -L/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3 -L/usr/i586-mandrake-linux/lib sse.o -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/crtend.o /usr/lib/crtn.o
I also tried the "equivalent" C code and compiling with gcc but I got the same problem.
This problem also exists for these other versions of gcc:
---
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
gcc version 2.95.3-5 (cygwin special)
---
Using builtin specs.
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable
-long-long --enable-cstdio=stdio --enable-clocale=generic --enable-languages=c,c++,f77,objc,java --program-suffix=-3.0 --enable-objc-gc --host=i686-mandrake-linux
Thread model: posix
gcc version 3.0
---
(But my 3.0 installation may not be correct, so you may want to ignore that)
>How-To-Repeat:
- compile the sample code on a PIII
- run it.
>Fix:
By adding three ints before my vectors:
...
int i,j,k;
vector ret __attribute((aligned(16)));
...
int i,j,k;
vector v1(...);
vector v2(...);
I get the proper alignment and the code runs successfully.
Of course, this is a less than good solution, since as soon as I use any sort of optimisation, the alignment is not good again.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-11 14:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-10 11:13 c++/3299: __attribute__((aligned(16))) seems to be ignored on x86 hubicka
-- strict thread matches above, loose matches on Subject: below --
2002-10-11 7:26 Jan Hubicka
2002-10-10 12:06 Gabriel Dos Reis
2001-06-20 10:56 ryants
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).