[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2023 03:09:53 +0200
From: Gabriel Ravier <gabravier@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Subject: Re: patches for C23
On 5/3/23 21:33, 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 <dalias@...c.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@...c.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.
GCC 3.x ??? I understand wanting backwards compatibility but compiler
versions from barely after the turn of the century seem like a bit far,
I guess it's admirable that musl works with versions of software that
are older than I am, but at some point I have to wonder if even a single
person in the world actually finds it useful to be able to build musl
with GCC 3 in 2023...
>
>> 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
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.
