c++/3299: __attribute__((aligned(16))) seems to be ignored on x86

c++/3299: __attribute__((aligned(16))) seems to be ignored on x86

[ryants]

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

Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86

[Jan Hubicka]

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
   

Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86

[Gabriel Dos Reis]

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

Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86

[hubicka]

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