[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250301075102.GT2724612@port70.net>
Date: Sat, 1 Mar 2025 08:51:02 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: Trevor Gross <tmgross@...ch.edu>, musl@...ts.openwall.com
Subject: Re: f128 aliases for long double math symbols
* Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
