Rich, on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker ) wrote: > On Wed, May 03, 2023 at 08:46:56PM +0200, Jₑₙₛ Gustedt wrote: > > Rich, > > > > on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker > > ) wrote: > > > > > On Wed, May 03, 2023 at 05:11:11PM +0200, Jₑₙₛ Gustedt wrote: > [...] > [...] > > > [...] > > > [...] > [...] > [...] > > > > > > Again, there are not multiple versions of musl with different > > > features depending on which compiler was used to compile them. > > > There is one unified feature set. There are not configure-time or > > > compile-time decisions about which features to support. > > > > This sounds a bit dogmatic > > Yes, it's one of the core principles of musl: that we don't have > build-time-selectable feature-set like uclibc did. > > > and also unrealistic. As said the dependency > > on compiler builtins undermines that approach. Future versions of > > gcc and clang will soon support `va_start` with only one parameter > > for example. Musl will just be dependent on that compiler feature. > > No it won't. None of the code in musl calls or needs to call va_start > with one parameter. You're confusing ?? > header-level stuff that a c23 > application might depend on, with build dependencies of libc. > > > How will you do with optional features, then? For example decimal > > floating point? This will never be added to musl? (Nobody will > > probably backport support for them to very old gcc versions, for > > example, or even to more recent versions of clang) > > Decimal float math library will likely be left to a third-party > library implementation. > > Decimal float in printf, if that becomes a thing, will be done the > same way as int128: stub to pop the arguments, and 100% integer code > to actually work with the data. > [...] > > > > > > The compiler used to compile musl and the compiler used to > > > compile the application using musl have nothing to do with each > > > other except sharing a baseline ABI target. > > > > Yes, exactly. And one supporting `__int128` and the other that > > doesn't basically wouldn't interfere. > > The premise here is that applications and libc are being built by > possibly different people with different tools. If I have a system > built with gcc 5.3, I can't build C23 applications, but I might get a > dynamically-linked C23 binary from someone who can. That binary needs > to run with my musl-1.2.7 (made-up number) libc.so because the C > language version the binary was generated from (or whether it was even > C at all) is irrelevant. The interface surface is just the musl ABI > surface. > > > For the support of `__int128`: gcc has this since ages on 64 bit > > archs, is there any such arch out there where this support is > > changing according to versions of gcc that are still in use? So if > > we make the > > We also support pcc, cparser+libfirm, etc. on archs they support. Not > just gcc. And gcc back to 3.x. > > > availability of `__int128` dependent on `UINTPTR_WIDTH` being 64, > > would that be acceptable for you? Or an even more dependent approach > > with special casing architectures where this is available since > > always? > > It's not really "special casing archs where this is available since > always". It's more like the other way around, "not special casing > archs where __int128 is a guaranteed part of the baseline psABI". For > those we can just let the default C implementation be used. For the > rest we need a (completely trivial) asm stub that pops the arg > according to the variadic argument ABI for the arch. This really isn't > that big a deal. It's a few instructions at most. I would still prefer that on those archs where there is `__int128` or `_BitInt(128)` (for the latter basically all C23 compilers, I think) that the default is done with that compiler support. We should leave to the compiler people what they do best ;-) This leaves us with fallback code to write that will probably rarely be used. Also, I have difficulties to asses the effort that is needed. There are the `printf`, `scanf` and the new bit-fiddeling interfaces. For the latter the current proposal is to have them implemented as shallow static inline functions. That would a bit complicated without compiler support. In all to me this sounds like a substantial effort in implementation and coordination. What is the way forward, here? Thanks Jₑₙₛ -- :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Université de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::