values of FE_TONEAREST...

values of FE_TONEAREST...

[Paul Zimmermann]

       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

Re: values of FE_TONEAREST...

[Florian Weimer]

* 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

Re: values of FE_TONEAREST...

[Joseph Myers]

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

Re: values of FE_TONEAREST...

[Joseph Myers]

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