This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [doc patch] document powerpc abi changes
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: gcc-patches at gcc dot gnu dot org, David Edelsohn <dje at watson dot ibm dot com>,Andreas Jaeger <aj at suse dot de>
- Date: Mon, 22 Nov 2004 14:19:12 +0100 (CET)
- Subject: Re: [doc patch] document powerpc abi changes
- References: <20041122032509.GG31866@bubble.modra.org>
Thanks for patch, Alan!
This is fine, with minor changes.
On Mon, 22 Nov 2004, Alan Modra wrote:
> + <li>GCC 3.4 releases have a number of fixes for PowerPC and PowerPC64
> + <a href="powerpc-abi.html"> ABI incompatibilities</a>
^^^
Please avoid the extra blank here.
> +<h4>PowerPC64 Linux</h4>
> + <ul>
> + <li> By default, PowerPC64 Linux now uses natural alignment of
> + structure elements.
We need to use GNU/Linux here (in both cases, and in the following) to
honor a request by RMS for us to do so.
> + special rules for structs starting with a double, can be chosen with
> + -malign-power. This change may result in incompatibility between
<code>-malign-power</code>
> + <li>-mabi=altivec is now the default rather than -mabi=no-altivec.</li>
<code>...</code> for both options here as well.
> +++ powerpc-abi.html 2004-11-22 13:31:16.534935949 +1030
> +<head>
> +<title>PowerPC ABI Changes in GCC 3.4 - GNU Project - Free Software Foundation (FSF)</title>
> +</head>
You can omit the "- GNU Project..." part; it will be add automatically.
(This was one of the requests that RMS made wrt. the GCC web pages to
have them in sync with the regular FSF pages.)
> + releases did not follow the proper calling conventions. These
> + fixes unfortunately did not all happen in one release, so in certain
> + rare cases code will be incompatible when using different version
> + compilers within the release series.</p>
"compiler versions" instead of "version compilers"? (Note that I am not
a native speaker, so if you and David say this is fine as is, it certainly
is. ;-) )
> + <li>_Complex integer types smaller than _Complex long, and _Complex
> + floating point types smaller than _Complex double were passed and
Please use <code>_Complex</code>, <code>_Complex long</code>, etc., and
GNU/Linux instead of just Linux.
> + <li>Under -mabi=altivec, PowerPC64 Linux used to pass vector args to
<code>...</code>
> + non-prototyped functions only in vector registers. Without a
> + prototype the arg is supposed to be passed in both vector registers
> + and in gprs or on the stack.</li>
Perhaps use "arguments" instead of "args"?
> + <li>DWARF2 debug information failed to use the correct numbers for
> + registers other than gprs or fprs. This affected both PowerPC and
> + PowerPC64 Linux.</li>
Perhaps spell out "fpr" (and "gpr") the first time these are being used?
On the other hand, those caring for ABI details really are supposed to
know about this, so take this is a minor suggestion.
> + <ul>
> + <li>Zero size arrays were incorrectly passed by reference in GCC
> + 3.3.1 and GCC 3.3.0, a regression from GCC 3.2. This was also fixed
> + in GCC 3.3.2.</li>
s/also// ?
> + <li>Small structures passed by value were passed at the wrong end of
> + registers, or padded at the wrong end in memory, or passed on the
> + stack when they should be passed in registers. AIX and PowerPC64
> + Linux support has been changed to comply with their respective ABIs,
GNU/Linux, also in the following.
> + which necessarily introduces an incompatibility with GCC 3.3.
> + "Small" here means less than eight bytes for the 64 bit
> + ABIs, and less than four bytes for AIX-32.</li>
64-bit.
> + <li>Under -mabi=no-altivec, vector parameters were not aligned, and
<code>, also in the following.
> + 32 bit and 64 bit. The fix necessarily introduces an incompatibility
32-bit, 64-bit.
> + where arguments were to be found. Affected were: all _Complex types,
> + 128 bit long double, and vectors under -mabi=altivec when all altivec
> + registers had been used.</li>
128-bit, <code>_Complex</code> (also in the following).
Gerald