Jan Beulich jbeulich@suse.com
Mon Aug 16 08:59:43 GMT 2021

• Previous message (by thread): [PATCH] x86: Don't pad .tfloat output
• Next message (by thread): [PATCH] x86: Don't pad .tfloat output
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

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.

Jan

---

• Previous message (by thread): [PATCH] x86: Don't pad .tfloat output
• Next message (by thread): [PATCH] x86: Don't pad .tfloat output
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

More information about the Binutils mailing list