This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for n32/n64 structure returns
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: 13 Sep 2003 10:11:15 +0100
- Subject: Re: Patch for n32/n64 structure returns
- References: <wvnn0dc44hg.fsf@talisman.cambridge.redhat.com>
Richard Sandiford <rsandifo@talisman.cambridge.redhat.com> writes:
> OK to install? If so, I'll whip up something for changes.html.
Here's a patch to the install & release notes. In mips-abi.html, parts
A-D are already committed. Parts E and F are implemented by the structure
return patch.
Richard
Index: doc/install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.223
diff -c -d -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.223 install.texi
*** doc/install.texi 26 Aug 2003 18:47:26 -0000 1.223
--- doc/install.texi 13 Sep 2003 08:38:14 -0000
*************** test.o: ELF N32 MSB mips-4 @dots{}
*** 2959,2981 ****
instead, you should set the environment variable @env{CC} to @samp{cc
-n32 -mips3} or @samp{gcc -mips3} respectively before configuring GCC@.
GCC on IRIX 6 is usually built to support both the N32 and N64 ABIs. If
you build GCC on a system that doesn't have the N64 libraries installed,
you need to configure with @option{--disable-multilib} so GCC doesn't
try to use them. Look for @file{/usr/lib64/libc.so.1} to see if you
have the 64-bit libraries installed.
! You must @emph{not} use GNU @command{as} (which isn't built anyway as of
! binutils 2.11.2) on IRIX 6 platforms; doing so will only cause problems.
!
! GCC does not currently support generating O32 ABI binaries in the
! @samp{mips-sgi-irix6} configurations. It is possible to create a GCC
! with O32 ABI only support by configuring it for the @samp{mips-sgi-irix5}
! target and using a patched GNU @command{as} 2.11.2 as documented in the
! @uref{#mips-sgi-irix5,,@samp{mips-sgi-irix5}} section above. Using the
! native assembler requires patches to GCC which will be included in a
! future release. It is
! expected that O32 ABI support will be available again in a future release.
The @option{--enable-threads} option doesn't currently work, a patch is
in preparation for a future release. The @option{--enable-libgcj}
--- 2959,2976 ----
instead, you should set the environment variable @env{CC} to @samp{cc
-n32 -mips3} or @samp{gcc -mips3} respectively before configuring GCC@.
+ Do not use versions of GNU @command{as} earlier than 2.14 on IRIX 6
+ platforms; they are known not to work correctly.
+
GCC on IRIX 6 is usually built to support both the N32 and N64 ABIs. If
you build GCC on a system that doesn't have the N64 libraries installed,
you need to configure with @option{--disable-multilib} so GCC doesn't
try to use them. Look for @file{/usr/lib64/libc.so.1} to see if you
have the 64-bit libraries installed.
! The @samp{mips-sgi-irix6} configuration cannot generate O32 binaries.
! You can create a separate O32-only compiler by configuring for
! @samp{mips-sgi-irix6o32}.
The @option{--enable-threads} option doesn't currently work, a patch is
in preparation for a future release. The @option{--enable-libgcj}
*************** to build despite this, running into an i
*** 2986,3008 ****
@command{ld}. A sure fix is to increase this limit (@samp{ncargs}) to
its maximum of 262144 bytes. If you have root access, you can use the
@command{systune} command to do this.
-
- GCC does not correctly pass/return structures which are
- smaller than 16 bytes and which are not 8 bytes. The problem is very
- involved and difficult to fix. It affects a number of other targets also,
- but IRIX 6 is affected the most, because it is a 64-bit target, and 4 byte
- structures are common. The exact problem is that structures are being padded
- at the wrong end, e.g.@: a 4 byte structure is loaded into the lower 4 bytes
- of the register when it should be loaded into the upper 4 bytes of the
- register.
-
- GCC is consistent with itself, but not consistent with the SGI C compiler
- (and the SGI supplied runtime libraries), so the only failures that can
- happen are when there are library functions that take/return such
- structures. There are very few such library functions. Currently this
- is known to affect @code{inet_ntoa}, @code{inet_lnaof},
- @code{inet_netof}, @code{inet_makeaddr}, and @code{semctl}. Until the
- bug is fixed, GCC contains workarounds for the known affected functions.
See @uref{http://freeware.sgi.com/,,http://freeware.sgi.com/} for more
information about using GCC on IRIX platforms.
--- 2981,2986 ----
Index: gcc-3.4/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/changes.html,v
retrieving revision 1.46
diff -c -d -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.46 changes.html
*** gcc-3.4/changes.html 10 Sep 2003 04:54:05 -0000 1.46
--- gcc-3.4/changes.html 13 Sep 2003 09:08:55 -0000
***************
*** 32,40 ****
in this release</a>.</li>
<li>GCC now requires an ISO C90 (ANSI C89) C compiler to build.
K&R C compilers will not work.</li>
! <li>On some MIPS targets, the code generated by this release
! will not be binary compatible with previous releases.
! See <a href="#mips_abi">below</a> for details.</li>
</ul>
<h2>General Optimizer Improvements</h2>
--- 32,40 ----
in this release</a>.</li>
<li>GCC now requires an ISO C90 (ANSI C89) C compiler to build.
K&R C compilers will not work.</li>
! <li>The code generated for certain MIPS targets
! <a href="mips-abi.html">will not be binary compatible</a>
! with earlier releases.</li>
</ul>
<h2>General Optimizer Improvements</h2>
***************
*** 293,311 ****
and should work with any MIPS I (<code>mips-*</code>) or MIPS III
(<code>mips64-*</code>) configuration.</li>
! <li><a name="mips_abi">n32 and n64 MIPS targets now pass all
! structures by value.</a> While this change brings GCC closer
! to ABI compliance, it will unfortunately break binary compatibility
! with earlier releases. A structure used to be passed by reference if:
! <ul>
! <li>the target was big-endian;</li>
! <li>the structure was bigger than 8 bytes;</li>
! <li>the structure's size was not a multiple of 8 bytes; and</li>
! <li>the first word of the structure would have been passed in
! a register.</li>
! </ul>
! Note that only big-endian n32 & n64 targets (such as IRIX 6) are
! affected.</li>
</ul>
<h2><a name="obsolete_systems">Obsolete Systems</a></h2>
--- 293,301 ----
and should work with any MIPS I (<code>mips-*</code>) or MIPS III
(<code>mips64-*</code>) configuration.</li>
! <li>Several <a href="mips-abi.html">ABI bugs</a> in the MIPS port
! have been fixed. Unfortunately, these changes will break binary
! compatibility with earlier releases.</li>
</ul>
<h2><a name="obsolete_systems">Obsolete Systems</a></h2>
*** /dev/null Tue Jun 17 23:06:41 2003
--- gcc-3.4/mips-abi.html Sat Sep 13 10:15:25 2003
***************
*** 0 ****
--- 1,347 ----
+ <html>
+
+ <head>
+ <title>MIPS ABI Changes in GCC 3.4</title>
+ </head>
+
+ <body>
+
+ <p>GCC 3.4 fixes several cases in which earlier releases would not
+ follow the MIPS calling conventions. This document describes
+ each fix and the kind of code that would be affected by it.
+ In each case, GCC 3.4 will not be binary compatible with earlier
+ releases.</p>
+
+ <p>Most of the fixes are related to the handling of structure
+ and union types. In the summary below, "aggregate" refers
+ to both structures and unions.</p>
+
+ <p>Note that IRIX 6 configurations used to work around
+ <a href="#B">B</a> and <a href="#E">E</a> by providing wrappers
+ for certain libc functions. These wrappers are not needed for 3.4
+ and have been removed. It should be possible to link code generated
+ by GCC 3.4 directly with code generated by SGI's compilers.</p>
+
+ <h3>A. Small aggregate arguments (1)</h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>o32</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>little</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>an aggregate argument is passed in a register; and</li>
+ <li>that argument is smaller than 4 bytes.</li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The register would be padded at the least significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td>The register is padded at the most significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>struct s { char c[2]; };
+ void f (struct s x);</pre>
+
+ <p><code>x</code> is passed in argument register <code>$4</code>,
+ which is laid out as follows:</p>
+
+ <table cellpadding="4">
+ <tr align="center">
+ <th></th> <th>7-0</th> <th>15-8</th> <th>23-16</th> <th>31-24</th>
+ </tr>
+
+ <tr align="center">
+ <th align="left">Old behavior</td>
+ <td>padding</td> <td>padding</td> <td>c[0]</td> <td>c[1]</td>
+ </tr>
+
+ <tr align="center">
+ <th align="left">New behavior</td>
+ <td>c[0]</td> <td>c[1]</td> <td>padding</td> <td>padding</td>
+ </tr>
+ </table></td>
+ </tr>
+ </table>
+
+ <h3><a name="B">B. Small aggregate arguments (2)</a></h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>n32 and n64</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>big</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>an aggregate argument is passed in a register; and</li>
+ <li>that argument is smaller than 8 bytes.</li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The register would be padded at the most significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td>The register is padded at the least significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>struct s { char c[2]; };
+ void f (struct s x);</pre>
+
+ <p><code>x</code> is passed in argument register
+ <code>$4</code>, which is laid out as follows:</p>
+
+ <table cellpadding="4">
+ <tr align="center">
+ <th></th>
+ <th>63-56</th> <th>55-48</th> <th>47-40</th> <th>39-32</th>
+ <th>31-24</th> <th>23-16</th> <th>15-8</th> <th>7-0</th>
+ </tr>
+
+ <tr align="center">
+ <th align="left">Old behavior</td>
+ <td>padding</td> <td>padding</td> <td>padding</td> <td>padding</td>
+ <td>padding</td> <td>padding</td> <td>c[0]</td> <td>c[1]</td>
+ </tr>
+
+ <tr align="center">
+ <th align="left">New behavior</td>
+ <td>c[0]</td> <td>c[1]</td> <td>padding</td> <td>padding</td>
+ <td>padding</td> <td>padding</td> <td>padding</td> <td>padding</td>
+ </tr>
+ </table></td>
+ </tr>
+ </table>
+
+ <h3>C. Large aggregate arguments</h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>n32 and n64</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>either</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>an aggregate argument is passed to a function;</li>
+ <li>the aggregate's size is not a multiple of 8 bytes; and</li>
+ <li>there are enough argument registers to hold some of
+ the aggregate, but not enough to hold all of it.</li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The argument would be passed by reference.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td>The argument is passed by value.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>struct s { int i[17]; };
+ void f (struct s x);</pre>
+
+ <p>It would take 9 registers to hold <code>x</code>, but
+ only 8 argument registers are available. Since <code>x</code>'s
+ size is not a multiple of 8, previous releases would pass it by
+ reference (that is, they would pass a pointer to <code>x</code>
+ in <code>$4</code>).</p>
+
+ <p>The new behavior is to pass <code>x</code> by value.
+ The first 8 words are passed in argument registers and
+ the last is passed on the stack.</p></td>
+ </tr>
+ </table>
+
+ <h3>D. Single-field structure arguments</h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>o32, o64, n32 and n64</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>either</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>a structure containing a single field is passed by value;
+ and</li>
+ <li>that field has a floating-point type.</li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The structure would be treated like a scalar value of the same
+ floating-point type. For example, a structure containing a
+ <code>float</code> field would be treated in the same way as a
+ scalar <code>float</code> value.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td><p>There is no special treatment for such structures.
+ Note however that the usual n32 and n64 rules still hold:
+ naturally-aligned fields of type <code>double</code> are
+ passed in floating-point registers.</p></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>struct s { float f; };
+ void f (struct s x);</pre>
+
+ <p>GCC used to pass <code>x</code> in <code>$f12</code>.
+ Now it passes it in <code>$4</code>, just like any other
+ structure.</p></td>
+ </tr>
+ </table>
+
+ <h3><a name="E">E. Structure return values</a></h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>n32 and n64</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>big</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>an aggregate is returned by value;</li>
+ <li>that aggregate is smaller than 16 bytes;</li>
+ <li>its size is not a multiple of 8 bytes; and</li>
+ <li>if it is a structure, either:
+ <ol>
+ <li>it has more than two fields; or</li>
+ <li>it has at least one non-floating-point field.</li>
+ </ol></li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The return register would be padded at the most significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td>The return register is padded at the least significant end.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>struct s { char c[3]; };
+ struct s f ();</pre>
+
+ <p>f() returns its value in <code>$2</code>, which is laid
+ out as follows:</p>
+
+ <table cellpadding="4">
+ <tr align="center">
+ <th></th>
+ <th>63-56</th> <th>55-48</th> <th>47-40</th> <th>39-32</th>
+ <th>31-24</th> <th>23-16</th> <th>15-8</th> <th>7-0</th>
+ </tr>
+
+ <tr align="center">
+ <th align="left">Old behavior</td>
+ <td>padding</td> <td>padding</td> <td>padding</td> <td>padding</td>
+ <td>padding</td> <td>c[0]</td> <td>c[1]</td> <td>c[2]</td>
+ </tr>
+
+ <tr align="center">
+ <th align="left">New behavior</td>
+ <td>c[0]</td> <td>c[1]</td> <td>c[2]</td> <td>padding</td>
+ <td>padding</td> <td>padding</td> <td>padding</td> <td>padding</td>
+ </tr>
+ </table></td>
+ </tr>
+ </table>
+
+ <h3>F. Complex return values</h3>
+
+ <table cellpadding="4">
+ <tr valign="top">
+ <th align="right">Affected ABIs</th>
+ <td>n32 and n64</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Endianness</th>
+ <td>either</th>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Conditions</th>
+ <td><ul>
+ <li>a function returns a complex floating-point value.</li>
+ </ul></td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Old behavior</th>
+ <td>The value would be returned in <code>$f0</code> and
+ <code>$f1</code>.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">New behavior</th>
+ <td>The value is returned in <code>$f0</code> and <code>$f2</code>.</td>
+ </tr>
+
+ <tr valign="top">
+ <th align="right">Example</th>
+ <td><pre>_Complex float f ();</pre></td>
+ </tr>
+ </table>
+
+ </body>
+ </html>