| Message ID | CAMe9rOo331GJdiQ-wK8cZiY-ZeN1vXBUV8Cnn6QsdZKHHsVMUg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
> On Fri, Jun 22, 2012 at 11:15 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> > > >> > >> Here is the patch for invoke.texi. OK to install? > >> > >> I will prepare a similar one for news.html. > >> > >> Thanks. > >> > >> -- > >> H.J. > >> --- > >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > >> index 029a7ab..87e0d1c 100644 > >> --- a/gcc/doc/invoke.texi > >> +++ b/gcc/doc/invoke.texi > >> @@ -13579,9 +13579,18 @@ the default is 4 (16 bytes or 128 bits). > >> > >> @strong{Warning:} When generating code for the x86-64 architecture with > >> SSE extensions disabled, @option{-mpreferred-stack-boundary=3} can be > >> -used to keep the stack boundary aligned to 8 byte boundary. You must > >> -build all modules with @option{-mpreferred-stack-boundary=3}, including > >> -any libraries. This includes the system libraries and startup modules. > >> +used to keep the stack boundary aligned to 8 byte boundary. Since > >> +x86-64 ABI require 16 byte stack alignment, this is ABI incompatible and > >> +intended to be used in controlled environment where stack space is > >> +important limitation. This option will lead to wrong code when functions > >> +compiled with 16 byte stack alignment (such as functions from a standard > >> +library) are called with misaligned stack. In this case, SSE > >> +instructions may lead to misaligned memory access traps. In addition, > >> +variable arguments will be handled incorrectly for 16 byte aligned > >> +objects (including x87 long double and __int128), leading to wrong > >> +results. You must build all modules with > >> +@option{-mpreferred-stack-boundary=3}, including any libraries. This > >> +includes the system libraries and startup modules. > > > > This is not true in a strict sense. One can build some part with 16 byte > > alignment and just watch to not call from 8byte world to 16byte world, but I am > > fine with it. (I guess -mpreferred-stack-boundary=3 is something to try on > > recursion heavy benchmarks as some in SPEC and I would also expect resulting > > binary to just work most of time ;) > > > > OK, Thanks! > > Honza > >> > >> @item -mincoming-stack-boundary=@var{num} > >> @opindex mincoming-stack-boundary > > I am not sure if news.html is the best place for this. > How about putting it in gcc-4.8/changes.html? Does > it look OK? Yes, I meant changes.html, sorry. Just to have it documented since when this is allowed. Thanks, Honza
Index: ./gcc-4.8/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.2 diff -u -p -r1.2 changes.html --- ./gcc-4.8/changes.html 28 Apr 2012 01:58:33 -0000 1.2 +++ ./gcc-4.8/changes.html 22 Jun 2012 18:23:01 -0000 @@ -61,9 +61,24 @@ <!-- <h2 id="targets">New Targets and Target Specific Improvements</h2> - --> +<h3>IA-32/x86-64</h3> + <ul> + <li>Allow <code>-mpreferred-stack-boundary=3</code> for the x86-64 + architecture with SSE extensions disabled. Since x86-64 ABI require + 16 byte stack alignment, this is ABI incompatible and intended to be + used in controlled environment where stack space is important limitation. + This option will lead to wrong code when functions compiled with 16 byte + stack alignment (such as functions from a standard library) are called + with misaligned stack. In this case, SSE instructions may lead to + misaligned memory access traps. In addition, variable arguments will + be handled incorrectly for 16 byte aligned objects (including x87 + long double and __int128), leading to wrong results. You must build all + modules with <code>-mpreferred-stack-boundary=3</code>, including any + libraries. This includes the system libraries and startup modules.</li> + </ul> + <!-- <h2>Documentation improvements</h2> -->