re: Sparc64 compiler bug, fix requries ABI change

[matthew green <mrg%eterna.com.au@localhost>]

Martin Husemann writes:
> There is a bug in the in-tree gcc vs. the sparc ABI when passing structures
> with floating point members of special size to functions.
> 
> The full story is here:
> 
> 	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
> 
> The short story: gcc ICEs for me when trying to build Firefox 53.
> 
> There are two variants of the bug: one with an ICE, the other with
> silently generating non-ABI compliant code.
> 
> This is fixed in gcc 6, but never got backported by upstream due to the
> ABI change.
> 
> I would prefer to ignore the ABI change (given the high chance we would have
> run into the ICE variant instead of the silent one) and just backport
> the change for our in-tree compiler.

to quote the above:

---
It's a bug in the original implementation of the SPARC 64-bit calling
conventions dating back to 1998:

   /* There's no need to check this_slotno < SPARC_FP_ARG_MAX.
      If it wasn't true we wouldn't be here.  */

That's wrong for a 12- or 16-byte FP structure passed in slot #15,
which must be passed half in %d30 and half on the stack according to
SCD 2.4.1.

What's annoying is that, while for a 12-byte structure this results
in an ICE as in the case at hand, for a 16-byte structure containing
doubles this results in wrong code, in the form of a violation of
the SPARC 64-bit calling conventions (the second half of the
structure is passed in %d32 instead of on the stack).

So we are faced with the following alternative:
 1. Fix only the ICE and don't change GCC's ABI, IOW keep the ABI bug,
 2. Fix the ICE and the ABI bug, IOW change GCC's ABI.
---

in particular, since it either ICEs or does the wrong thing, fixing
it with an ABI backport is valid to me.


.mrg.