Re: [musl] patches for C23

[Rich Felker <dalias@libc.org>]

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:
> > > > Language/compiler baseline for building musl is not going to go
> > > > up, so this complicates some things, especially implementing the
> > > > int128 stuff. This will need pop_arg to call out to an
> > > > arch-provided asm function that bypasses the C type system to get
> > > > the nonexistent-type argument off the va_list and store it in a
> > > > pair of uint64_t.  
> > > 
> > > I don't see that. `pop_arg` just uses `va_arg` and that in turn is
> > > fixed to `__builtin_va_arg`. The proposed patches assume that if
> > > `__SIZEOF_INT128__` is defined by the compiler that then the
> > > compiler provides the `__int128` types and knows how to deal with
> > > them in `__builtin_va_arg`. Is there anything wrong with that
> > > assumtion?  
> > 
> > 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.

> 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.

Rich