From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22756 invoked by alias); 11 Oct 2002 14:26:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22740 invoked by uid 71); 11 Oct 2002 14:26:00 -0000 Date: Fri, 11 Oct 2002 07:26:00 -0000 Message-ID: <20021011142600.22739.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jan Hubicka Subject: Re: c++/3299: __attribute__((aligned(16))) seems to be ignored on x86 Reply-To: Jan Hubicka X-SW-Source: 2002-10/txt/msg00456.txt.bz2 List-Id: The following reply was made to PR c++/3299; it has been noted by GNATS. From: Jan Hubicka To: Gabriel Dos Reis 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 * 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