* values of FE_TONEAREST...
@ 2021-06-24 7:22 Paul Zimmermann
2021-06-24 7:36 ` Florian Weimer
2021-06-24 18:02 ` Joseph Myers
0 siblings, 2 replies; 4+ messages in thread
From: Paul Zimmermann @ 2021-06-24 7:22 UTC (permalink / raw)
To: libc-alpha
Hi,
I'd like to have the opinion of GNU libc developers on this, especially those
who are also involved in Redhat Newlib:
https://mailman.oakapple.net/pipermail/cfp-interest/2021-June/002038.html
This was discussed in the last CFP meeting yesterday:
https://mailman.oakapple.net/pipermail/cfp-interest/2021-June/002048.html
Paul
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: values of FE_TONEAREST...
2021-06-24 7:22 values of FE_TONEAREST Paul Zimmermann
@ 2021-06-24 7:36 ` Florian Weimer
2021-06-24 18:19 ` Joseph Myers
2021-06-24 18:02 ` Joseph Myers
1 sibling, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2021-06-24 7:36 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: libc-alpha, vinschen
* Paul Zimmermann:
> I'd like to have the opinion of GNU libc developers on this, especially those
> who are also involved in Redhat Newlib:
>
> https://mailman.oakapple.net/pipermail/cfp-interest/2021-June/002038.html
>
> This was discussed in the last CFP meeting yesterday:
>
> https://mailman.oakapple.net/pipermail/cfp-interest/2021-June/002048.html
I think none of the libraries involved would want to go through the
hassle of an ABI transition. The values have been like this for a long
time.
There are of course other sources of binary incompatibility, such as
different type sizes.
Thanks,
Florian
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: values of FE_TONEAREST...
2021-06-24 7:36 ` Florian Weimer
@ 2021-06-24 18:19 ` Joseph Myers
0 siblings, 0 replies; 4+ messages in thread
From: Joseph Myers @ 2021-06-24 18:19 UTC (permalink / raw)
To: Florian Weimer; +Cc: Paul Zimmermann, vinschen, libc-alpha
On Thu, 24 Jun 2021, Florian Weimer via Libc-alpha wrote:
> There are of course other sources of binary incompatibility, such as
> different type sizes.
Indeed. The 32-bit Arm ABI includes CLIBABI
<https://github.com/ARM-software/abi-aa/releases/download/2021Q1/clibabi32.pdf>
which tries to provide some very limited support for object files to work
with multiple library implementations - only when the object file is built
in a special mode using a library with support for that mode (defining
_AEABI_PORTABILITY_LEVEL to a nonzero value), and only when that object
file is then used with a library that provides certain __aeabi_* symbols.
Neither glibc nor newlib supports _AEABI_PORTABILITY_LEVEL to build such
portable objects (see newlib discussion at
<https://sourceware.org/pipermail/newlib/2007/006328.html>). glibc has
limited support for *some* of the __aeabi_* symbols for *using* such
portable objects, but it's both incomplete (bug 15505) and sometimes
incorrect (bug 15500) and as far as I know those bugs have never caused
any practical problems for anyone. The 64-bit Arm ABI didn't keep this
feature at all; it doesn't seem it's actually of much use in practice.
Without such a feature that defines interfaces for use by portable object
files, you can't expect object files built with one library's headers to
work at all with another library. (In the glibc case, you can't
necessarily expect .o files or static libraries built with one glibc
version to work when linked with a newer glibc version either, since
symbol references are only bound to symbol versions at link time.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: values of FE_TONEAREST...
2021-06-24 7:22 values of FE_TONEAREST Paul Zimmermann
2021-06-24 7:36 ` Florian Weimer
@ 2021-06-24 18:02 ` Joseph Myers
1 sibling, 0 replies; 4+ messages in thread
From: Joseph Myers @ 2021-06-24 18:02 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: libc-alpha
On Thu, 24 Jun 2021, Paul Zimmermann wrote:
> Hi,
>
> I'd like to have the opinion of GNU libc developers on this, especially those
> who are also involved in Redhat Newlib:
>
> https://mailman.oakapple.net/pipermail/cfp-interest/2021-June/002038.html
You're only quoting the x86 values there. glibc has 17
architecture-specific bits/fenv.h headers, and most architectures have
their own values of the rounding mode macros that directly correspond to
that architecture's bits in the control register (and are different from
those for all other architectures). (AArch64 and Arm share the values of
the macros. So do MIPS and PowerPC and S/390.) That's before you get
into complications of different architectures supporting different sets of
rounding modes. (RISC-V has the hardware support needed for
FE_TONEARESTFROMZERO, though various glibc code and tests that handle all
the standard rounding modes would need updating to handle that one as well
before a definition of FE_TONEARESTFROMZERO could be added and work
reliably. PowerPC hardware supports eight decimal rounding modes, not
just the IEEE five.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-06-24 18:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-24 7:22 values of FE_TONEAREST Paul Zimmermann
2021-06-24 7:36 ` Florian Weimer
2021-06-24 18:19 ` Joseph Myers
2021-06-24 18:02 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).