tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

re: Sparc64 compiler bug, fix requries ABI change

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:
> 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.


Home | Main Index | Thread Index | Old Index