[musl] f128 aliases for long double math symbols

[musl] f128 aliases for long double math symbols

[Trevor Gross]

Hello all,

On platforms where `long double` is `_Float128`, glibc provides
aliases of math symbols. For example, on aarch64 `sinl` and `sinf128`
refer to the same function.

Would the same be welcome in musl? The advantage this provides is
certainty that the correct symbol is linked for `_Float128` operations
without knowledge of what the platform `long double` is configured to
(e.g. the ongoing PowerPC double-double to IEEE128 migration).

Best regards,
Trevor

Re: [musl] f128 aliases for long double math symbols

[Markus Wichmann]

Am Fri, Feb 28, 2025 at 06:36:09AM -0500 schrieb Trevor Gross:
> Hello all,
>
> On platforms where `long double` is `_Float128`, glibc provides
> aliases of math symbols. For example, on aarch64 `sinl` and `sinf128`
> refer to the same function.
>
> Would the same be welcome in musl? The advantage this provides is
> certainty that the correct symbol is linked for `_Float128` operations
> without knowledge of what the platform `long double` is configured to
> (e.g. the ongoing PowerPC double-double to IEEE128 migration).
>
> Best regards,
> Trevor

Is there any standard reserving these names and specifying their
meaning? As far as I can tell, this is purely a GNU extension. It
doesn't appear to be present on any other implementation whatsoever.

Therefore, musl will not be able to adopt these interfaces, as it would
run the risk of future incompatible standardization. Strictly speaking,
these names are in the application namespace, too.

Applications can verify their implementation's long double
representation with the values of the constants from <float.h>. Linking
a libc with an application when they have different ideas about what
long double means will break badly and must be prevented. But sinf128()
doesn't help with that.

In the past, similar ABI changes have been enabled by additional tooling
in the linker to recognize the disparity, e.g. by adding notes into the
object file, or writing special tags into the dynamic section (even
though I recall the error messages for these cases being subpar).
Mayhaps this is a better way forward.

Ciao,
Markus

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Fri, Feb 28, 2025 at 06:36:09AM -0500, Trevor Gross wrote:
> Hello all,
> 
> On platforms where `long double` is `_Float128`, glibc provides
> aliases of math symbols. For example, on aarch64 `sinl` and `sinf128`
> refer to the same function.
> 
> Would the same be welcome in musl? The advantage this provides is
> certainty that the correct symbol is linked for `_Float128` operations
> without knowledge of what the platform `long double` is configured to
> (e.g. the ongoing PowerPC double-double to IEEE128 migration).

Probably not. While the representations may be the same, as I
understand it long double and _Float128 are distinct types even when
the representations are the same. This means the signatures would be
mismatched and it would be UB calling the alias with the wrong
signature.

In addition, if the functions were standardized, it would violate the
requirement of non-equality of function pointers for distinct
functions.

The reasonable way to do this would probably be with wrapper functions
that just call the long double function. But in general musl also
avoids having the set of implemented functions vary by arch. And for
the most part we don't even have correct quad math library functions.
A few that have exact/exact-rounding requirements should be working,
but most give just ld80-equivalent or even double precision only.

Rich

Re: [musl] f128 aliases for long double math symbols

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2025-02-28 17:44:08 -0500]:

> On Fri, Feb 28, 2025 at 06:36:09AM -0500, Trevor Gross wrote:
> > Hello all,
> > 
> > On platforms where `long double` is `_Float128`, glibc provides
> > aliases of math symbols. For example, on aarch64 `sinl` and `sinf128`
> > refer to the same function.
> > 
> > Would the same be welcome in musl? The advantage this provides is
> > certainty that the correct symbol is linked for `_Float128` operations
> > without knowledge of what the platform `long double` is configured to
> > (e.g. the ongoing PowerPC double-double to IEEE128 migration).
> 
> Probably not. While the representations may be the same, as I
> understand it long double and _Float128 are distinct types even when
> the representations are the same. This means the signatures would be
> mismatched and it would be UB calling the alias with the wrong
> signature.
> 
> In addition, if the functions were standardized, it would violate the
> requirement of non-equality of function pointers for distinct
> functions.


these are now standard symbols in c23 annex H.11

http://port70.net/~nsz/c/c23/n3220.pdf

iirc these are originally from ts 18661-3 that aimed to bring
complete coverage of ieee 754-2008 fp standard to c before c2x
work started. glibc followed that and later c2x when it
got adopted there.

> 
> The reasonable way to do this would probably be with wrapper functions
> that just call the long double function. But in general musl also
> avoids having the set of implemented functions vary by arch. And for
> the most part we don't even have correct quad math library functions.
> A few that have exact/exact-rounding requirements should be working,
> but most give just ld80-equivalent or even double precision only.

i believe gcc provides consistent _Float128 across targets
which can be tested with macros. and i think it's more useful
than long double.

so if musl is compiled with new enough compiler we could
provide the symbols.. ideally the compiler/linker could
collapse the wrapper into an alias on targets where appropriate,
im not sure if distinct funcptr is needed, but i doubt the
toolchain would do such optimization.

a lot of new symbols are required for musl to be able to claim
conformance via feature test macros. but if somebody is willing
to put in the work it should be acceptable.

> 
> Rich

Re: [musl] f128 aliases for long double math symbols

[Florian Weimer]

* Rich Felker:

> In addition, if the functions were standardized, it would violate the
> requirement of non-equality of function pointers for distinct
> functions.

Is there really such a requirement for functions that have distinct
types?

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Sat, Mar 01, 2025 at 08:51:02AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2025-02-28 17:44:08 -0500]:
> > The reasonable way to do this would probably be with wrapper functions
> > that just call the long double function. But in general musl also
> > avoids having the set of implemented functions vary by arch. And for
> > the most part we don't even have correct quad math library functions.
> > A few that have exact/exact-rounding requirements should be working,
> > but most give just ld80-equivalent or even double precision only.
> 
> i believe gcc provides consistent _Float128 across targets
> which can be tested with macros. and i think it's more useful
> than long double.
> 
> so if musl is compiled with new enough compiler we could
> provide the symbols..

The problem with this and with adding *any* new interfaces that depend
on newly invented types is that it's impossible without either nasty
asm shims or requiring very new compiler versions and dropping support
for all non-monoculture compilers (firm, pcc, etc.) which are unlikely
to get support any time soon.

Since it's isolated functionality that doesn't have anything else in
libc depending on it, putting it in a separate third-party library
probably makes a lot more sense.

Rich

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Sat, Mar 01, 2025 at 09:29:20AM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> > In addition, if the functions were standardized, it would violate the
> > requirement of non-equality of function pointers for distinct
> > functions.
> 
> Is there really such a requirement for functions that have distinct
> types?

There's a requirement for function pointer non-equality regardless of
types. Function pointers can all be cast and compared freely as long
as they're only *called* with the correct type matching the
definition, and different functions cannot compare equal.

Rich

Re: [musl] f128 aliases for long double math symbols

[Thorsten Glaser]

Rich Felker dixit:
>On Sat, Mar 01, 2025 at 09:29:20AM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > In addition, if the functions were standardized, it would violate the
>> > requirement of non-equality of function pointers for distinct
>> > functions.
>>
>> Is there really such a requirement for functions that have distinct
>> types?

I cannot find anything related in my copy of C99 at least.

>different functions cannot compare equal.

But they are equal, on the implementation layer. The aliasing
is not done in C, so there’s no UB, and I’ve never seen any
wording to the effect of forbidding, say, aliasing memcpy and
memmove, or strcmp and strcoll (and memcpy and strxfrm).

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Mon, Mar 03, 2025 at 11:08:57AM +0000, Thorsten Glaser wrote:
> Rich Felker dixit:
> >On Sat, Mar 01, 2025 at 09:29:20AM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > In addition, if the functions were standardized, it would violate the
> >> > requirement of non-equality of function pointers for distinct
> >> > functions.
> >>
> >> Is there really such a requirement for functions that have distinct
> >> types?
> 
> I cannot find anything related in my copy of C99 at least.
> 
> >different functions cannot compare equal.
> 
> But they are equal, on the implementation layer. The aliasing

That's not how this works. That's not how any of this works.

An implementor does not go decide "oh, on the implementation layer,
I'm doing something different from the abstract machine, so I just get
to change the language to match how it works on the implementation
layer."

No, in that case the implementation is just incorrect. A C
implementation must always follow the "as-if rule", i.e. behave as if
the real machine and abstract machine match. The legal transformations
it can make are ones indistinguishable from the behavior defined for
the abstract machine.

> is not done in C, so there’s no UB, and I’ve never seen any
> wording to the effect of forbidding, say, aliasing memcpy and
> memmove, or strcmp and strcoll (and memcpy and strxfrm).

6.5.9 paragraph 6 reads:

     "Two pointers compare equal if and only if both are null
     pointers, both are pointers to the same object (including a
     pointer to an object and a subobject at its beginning) or
     function, both are pointers to one past the last element of the
     same array object, or one is a pointer to one past the end of one
     array object and the other is a pointer to the start of a
     different array object that happens to immediately follow the
     first array object in the address space."

Not if they're implemented with code at the same address. If they're
the *same function*.

Rich

Re: [musl] f128 aliases for long double math symbols

[Thorsten Glaser]

On Tue, 4 Mar 2025, Rich Felker wrote:

>Not if they're implemented with code at the same address. If they're
>the *same function*.

But they *are*!

I don’t see anything saying that, if I use the memmove implementation
for memcpy, they cannot be aliased to the same function pointer. (At
least in C99, haven’t looked at C23.)

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Tue, Mar 04, 2025 at 09:10:25PM +0100, Thorsten Glaser wrote:
> On Tue, 4 Mar 2025, Rich Felker wrote:
> 
> >Not if they're implemented with code at the same address. If they're
> >the *same function*.
> 
> But they *are*!
> 
> I don’t see anything saying that, if I use the memmove implementation
> for memcpy, they cannot be aliased to the same function pointer. (At
> least in C99, haven’t looked at C23.)

The standard defines a memmove function and a memcpy function. These
are two functions. Thereby they compare not equal. The fact that you
can make up some mechanism outside of the standard to use the same
definition for both doesn't somehow make them the same function.

Rich

Re: [musl] f128 aliases for long double math symbols

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2025-03-04 15:24:17 -0500]:

> On Tue, Mar 04, 2025 at 09:10:25PM +0100, Thorsten Glaser wrote:
> > On Tue, 4 Mar 2025, Rich Felker wrote:
> > 
> > >Not if they're implemented with code at the same address. If they're
> > >the *same function*.
> > 
> > But they *are*!
> > 
> > I don’t see anything saying that, if I use the memmove implementation
> > for memcpy, they cannot be aliased to the same function pointer. (At
> > least in C99, haven’t looked at C23.)
> 
> The standard defines a memmove function and a memcpy function. These
> are two functions. Thereby they compare not equal. The fact that you
> can make up some mechanism outside of the standard to use the same
> definition for both doesn't somehow make them the same function.
> 
> Rich

those have compatible type so the type argument does not work.

i dont think the standard explicitly requires unequal library
functions. in practice aliasing is widely used so de facto
portable code cannot rely on different address.

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Fri, Mar 07, 2025 at 06:17:30PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2025-03-04 15:24:17 -0500]:
> 
> > On Tue, Mar 04, 2025 at 09:10:25PM +0100, Thorsten Glaser wrote:
> > > On Tue, 4 Mar 2025, Rich Felker wrote:
> > > 
> > > >Not if they're implemented with code at the same address. If they're
> > > >the *same function*.
> > > 
> > > But they *are*!
> > > 
> > > I don’t see anything saying that, if I use the memmove implementation
> > > for memcpy, they cannot be aliased to the same function pointer. (At
> > > least in C99, haven’t looked at C23.)
> > 
> > The standard defines a memmove function and a memcpy function. These
> > are two functions. Thereby they compare not equal. The fact that you
> > can make up some mechanism outside of the standard to use the same
> > definition for both doesn't somehow make them the same function.
> 
> those have compatible type so the type argument does not work.

The type issue is completely separate. It's a matter of the library
implementation invoking UB with respect to the compiler implementation
by defining the function with a wrong type. This will break for
example with LTO or certain kinds of call integrity hardening that
check signatures. This one would be a non-issue if we decided we
control the entire implementation (e.g. only support traditional asm
linkage, no LTO or fancy hardening tooling) and simply define it as
working.

The issue at hand is one of the implementation not conforming to
requirements that applications are permitted to rely upon.

> i dont think the standard explicitly requires unequal library
> functions.

I don't see how you read that. The standard specifies two functions,
and specifies that different functions compare not-equal. It does not
rigorously define the word "different" but that's par for WG14.

> in practice aliasing is widely used so de facto
> portable code cannot rely on different address.

In practice a lot of non-conforming and broken things were done by
historical implementations. That's why musl exists.

Rich

Re: [musl] f128 aliases for long double math symbols

[Stephen Heumann]

On Mar 7, 2025, at 11:38 AM, Rich Felker <dalias@libc.org> wrote:
> 
>> i dont think the standard explicitly requires unequal library
>> functions.
> 
> I don't see how you read that. The standard specifies two functions,
> and specifies that different functions compare not-equal. It does not
> rigorously define the word "different" but that's par for WG14.

The response to DR#78 indicates memcpy and memmove may compare equal:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_078.html

That's an old DR for C90, so maybe you could argue it's not directly applicable to current standards, but at least at one time WG14 said that was allowed.

--Stephen Heumann

Re: [musl] f128 aliases for long double math symbols

[Thorsten Glaser]

On Fri, 7 Mar 2025, Rich Felker wrote:

>The type issue is completely separate. It's a matter of the library
>implementation invoking UB with respect to the compiler implementation

1. The library implementation does not need to use C.
2. The C standard explicitly allows the implementation itself
   to handwave numerous things that would otherwise be UB in
   application code, e.g. pre-C23 there was no way to write
   strchr(3) in conforming C.

>This will break for example with LTO or certain kinds of call integrity
>hardening that check signatures.

That’s a deficiency in these tools, but one that doesn’t prevent
environments where these tools are a nōn-issue from it.

>The issue at hand is one of the implementation not conforming to
>requirements that applications are permitted to rely upon.

That’s explicitly allowed by the standard.

>> i dont think the standard explicitly requires unequal library
>> functions.
>
>I don't see how you read that. The standard specifies two functions,
>and specifies that different functions compare not-equal. It does not
>rigorously define the word "different" but that's par for WG14.

It does not mandate that memcpy be different from memmove either
(in fact Stephen found the DR stating that they may indeed be equal).

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: [musl] f128 aliases for long double math symbols

[Rich Felker]

On Fri, Mar 07, 2025 at 08:09:28PM +0100, Thorsten Glaser wrote:
> On Fri, 7 Mar 2025, Rich Felker wrote:
> 
> >The type issue is completely separate. It's a matter of the library
> >implementation invoking UB with respect to the compiler implementation
> 
> 1. The library implementation does not need to use C.
> 2. The C standard explicitly allows the implementation itself
>    to handwave numerous things that would otherwise be UB in
>    application code, e.g. pre-C23 there was no way to write
>    strchr(3) in conforming C.

I think that agrees with what I said. The type issue is a type issue
because we demand analyzability and compatibility with type checking
tooling and, on a more abstract level, because we demand that the C in
musl be valid freestanding C that may depend on particular
implementation-defined behaviors and a small set of extensions, but
not on undefined behavior. This is a choice.

> >The issue at hand is one of the implementation not conforming to
> >requirements that applications are permitted to rely upon.
> 
> That’s explicitly allowed by the standard.
> 
> >> i dont think the standard explicitly requires unequal library
> >> functions.
> >
> >I don't see how you read that. The standard specifies two functions,
> >and specifies that different functions compare not-equal. It does not
> >rigorously define the word "different" but that's par for WG14.
> 
> It does not mandate that memcpy be different from memmove either
> (in fact Stephen found the DR stating that they may indeed be equal).

Indeed, the DR -- while garbage as written, not giving any rationale
for the answers -- settles that. I disagree with any interpretation
that it's allowed by the language of the standard as written, but as
we've seen that's often imprecise/ambiguous, and if the agreed-upon
resolution is that it's allowed, then it's allowed.

I don't think it's an allowance that I'd like to make use of, and I
don't see any clear indication that there's a general principle being
applied here rather than "oh yeah that sounds good to me".

Rich

Re: [musl] f128 aliases for long double math symbols

[Thorsten Glaser]

On Fri, 7 Mar 2025, Rich Felker wrote:

>because we demand analyzability and compatibility with type checking
>tooling and, on a more abstract level, because we demand that the C in
>musl be valid freestanding C that may depend on particular
>implementation-defined behaviors and a small set of extensions, but
>not on undefined behavior. This is a choice.
[…]
>I don't think it's an allowance that I'd like to make use of, and I

OK.

Mostly we were discussing this because you made it sound like it’s
not permitted for any implementation to do that, or for application
code to rely on implementations not doing that.

A choice, for musl, is fine (and while I don’t agree with all the
choices, you have my respect anyway).

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

[musl] Re: f128 aliases for long double math symbols

[Aaron Peter Bachmann]

*Florian Weimer

>* Rich Felker:
>
>> In addition, if the functions were standardized, it would violate the
> requirement of non-equality of function pointers for distinct
>> functions.
>
>Is there really such a requirement for functions that have distinct
>types?
>

Surprisingly, there is no such requirement for library functions.
For long time I lived with this misconception as well.
Following defect report clarifies this:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_078.html

Regards, Aaron Peter Bachmann