[PATCH] x86: Don't pad .tfloat output

[H.J. Lu]

On Mon, Aug 16, 2021 at 1:59 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.08.2021 10:17, Andreas Schwab wrote:
> > On Aug 16 2021, Jan Beulich via Binutils wrote:
> >
> >> This leaves users without any ABI-conforming way to produce double
> >> extended precision values, short of hand-coding the padding.
> >
> > If you want to use the C ABI, you should use a C compiler.  On the
> > assembler level, double extended precision have 10 bytes, which is what
> > the FPU reads and writes.  The manual clearly documents .tfloat as
> > producing 80-bit (ten byte) reals.
>
> Well, the other consistent arrangement we could move to is for no
> padding to ever get emitted - including .dc.x, .dcb.x, and .ds.x.
> Personally I view this as less useful, but I could see us going
> this route. The one thing that's a no-go imo is the inconsistent
> state prior to the patch series (and it remaining that way on
> other architectures also supporting double extended precision),
> including this inconsistency even getting spelled out in the
> documentation.

My patch removes paddings for .tfloat with hex, .dc.x, .dcb.x,
and .ds.x.

-- 
H.J.