[PATCH] i386: Cleanup i386/i386elf.h and align it's return convention with the SVR4 ABI

Uros Bizjak ubizjak@gmail.com
Fri Oct 30 20:05:43 GMT 2020


> As observed a number of years ago in the following thread, i386/i386elf.h has not been
> kept up to date:
>
> https://gcc.gnu.org/pipermail/gcc/2013-August/209981.html
>
> This patch does the following cleanup:
>
> 1. The return convention now follows the i386 and x86_64 SVR4 ABIs again. As discussed
> in the above thread, the current return convention does not match any other target or
> existing ABI, which is problematic since the current approach is inefficient (particularly on
> x86_64-elf) and confuses other tools like GDB (unfortunately that thread did not lead to any
> fix at the time).
>
> 2. The default version of ASM_OUTPUT_ASCII from elfos.h is used. As mentioned in the
> cleanup of i386/sysv4.h [1] the ASM_OUTPUT_ASCII implementation then used by sysv4.h,
> and currently used by i386elf.h, has a significantly higher computation complexity than the
> default version provided by elfos.h.
>
> The patch has been tested on i386-elf and x86_64-elf hosted on x86_64-linux, fixing a
> number failing tests that were expecting the SVR4 ABI return convention. It has also been
> bootstrapped and tested on x86_64-pc-linux-gnu without regression.
>
> If approved, I'll need a maintainer to kindly commit on my behalf.
>
> Thanks,
>
> Pat Bernardi
> Senior Software Engineer, AdaCore
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2011-February/305559.html

Looking at the [1], it looks that i386elf.h suffered some bitrot.
Probably nobody cares much for {i386,x86_64}-elf nowadays.

So, I think, uder reasons explained in [1], and based on your testing,
that the patch should be committed to the mainline to fix the ABI
issues. However, I wonder if the ABI change is severe enough to
warrant a compile-time warning?

> 2020-08-18  Pat Bernardi  <bernardi@adacore.com>
>
> gcc/ChangeLog
>
> * config/i386/i386elf.h (SUBTARGET_RETURN_IN_MEMORY): Remove.
> (ASM_OUTPUT_ASCII): Likewise.
> (DEFAULT_PCC_STRUCT_RETURN): Define.
> * config/i386/i386.c (ix86_return_in_memory): Remove
> SUBTARGET_RETURN_IN_MEMORY.

-/* The ELF ABI for the i386 says that records and unions are returned
-   in memory.  */
-
-#define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
- (TYPE_MODE (TYPE) == BLKmode \
- || (VECTOR_MODE_P (TYPE_MODE (TYPE)) && int_size_in_bytes (TYPE) == 8))
+/* Define DEFAULT_PCC_STRUCT_RETURN to 1 because the i386 SVR4 ABI returns
+   records and unions in memory. ix86_option_override_internal will overide
+   this flag when compiling 64-bit code as we never do pcc_struct_return
+   scheme on x86-64.  */
+#undef DEFAULT_PCC_STRUCT_RETURN
+#define DEFAULT_PCC_STRUCT_RETURN 1

The documentation says:

--cut here--
DEFAULT_PCC_STRUCT_RETURN Define this macro to be 1 if all structure
and union return values must be in memory. Since this results in
slower code, this should be defined only if needed for compatibility
with other compilers or with an ABI. If you define this macro to be 0,
then the conventions used for structure and union return values are
decided by the RETURN_IN_MEMORY macro.

If not defined, this defaults to the value 1.
--cut here--

So, is it necessary to define DEFAULT_PCC_STRUCT_RETURN ?

Uros.


More information about the Gcc-patches mailing list