Re: [musl] patches for C23

[Rich Felker <dalias@libc.org>]

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 <dalias@libc.org>)
> wrote:
> 
> > On Wed, May 03, 2023 at 05:11:11PM +0200, Jₑₙₛ Gustedt wrote:
> > > Rich,
> > > 
> > > on Wed, 3 May 2023 10:16:19 -0400 you (Rich Felker
> > > <dalias@libc.org>) wrote:
> > >   
> > > > On Wed, May 03, 2023 at 11:12:46AM +0200, Jₑₙₛ Gustedt wrote:  
> >  [...]  
> >  [...]  
> > > > 
> > > > Yes. We don't require a compiler that has an __int128.  
> > > 
> > > sure, but all the uses are protected by `__SIZEOF_INT128__`. So if
> > > the compiler don't has this, they will not see that code when
> > > compiling musl.  
> > 
> > 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.

> > > Also application side compilation with a different compiler that has
> > > no `__int128` would not see these interfaces, so such application
> > > code can never call into the library with `__int128` types.  
> > 
> > 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.

Rich