[PATCH] x86: Don't pad .tfloat output
H.J. Lu
hjl.tools@gmail.com
Tue Aug 17 12:37:52 GMT 2021
On Tue, Aug 17, 2021 at 12:49 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.08.2021 15:40, H.J. Lu wrote:
> > On Sun, Aug 15, 2021 at 11:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 15.08.2021 22:34, H.J. Lu wrote:
> >>> .tfloat output should always be 10 bytes without padding, independent
> >>> of psABIs.
> >>
> >> I disagree. It's been a long standing bug. I can see that affecting
> >> existing code isn't nice, so I could see us emit e.g. a warning for
> >> the time being. In the worst case we might add a command line option
> >> to drive the behavior.
> >>
> >>> In glibc, x86 assembly codes expect 10-byte .tfloat output.
> >>> This also changes .ds.x output and .tfloat output with hex input to
> >>> match .tfloat output.
> >>
> >> This leaves users without any ABI-conforming way to produce double
> >> extended precision values, short of hand-coding the padding. Even if
> >> you were really going to insist that retaining the broken behavior
> >> of .tfloat is necessary, a directive providing correct behavior
> >> should be available. This might then be .d{c,cb,s}.x, or something
> >> new. But as said - to me this really would only be a last resort.
> >> Whoever introduced .tfloat in its present way screwed up, and
> >> whoever forgot to fix .tfloat for x86-64 didn't even pay attention
> >> to the ABI difference.
> >>
> >>> PR gas/28230
> >>> * config/tc-i386.c (x86_tfloat_pad): Removed.
> >>> * config/tc-i386.h (X_PRECISION_PAD): Changed to 0.
> >>> (x86_tfloat_pad): Removed.
> >>> * testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined,
> >>> add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x
> >>> directives.
> >>> * testsuite/gas/i386/i386.exp (ASFLAGS): Append
> >>> "--defsym NO_TFLOAT_PADDING=1" when running the fp test.
> >>
> >> I'm afraid I don't understand the games you play here: If you
> >> really thought .tfloat should not emit ABI-conforming data, then
> >> why would you bother introducing NO_TFLOAT_PADDING to allow for
> >> alternative behavior?
> >
> > Since I don't want to change fp-elf32.d nor fp-elf64.d, I added paddings
> > manually. fp.d doesn't expect paddings.
>
> But with .tfloat no longer honoring ABI there's no need for fp-elf*.d
> anymore. All targets ought to now conform to fp.d.
>
I am checking in this patch.
--
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Always-run-fp-tests.patch
Type: text/x-patch
Size: 9838 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20210817/6656547a/attachment.bin>
More information about the Binutils
mailing list