![]() |
|
Message-ID: <Z8IZNno-AL0sqYjn@voyager> Date: Fri, 28 Feb 2025 21:14:46 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: Trevor Gross <tmgross@...ch.edu> Subject: Re: f128 aliases for long double math symbols 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
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.