mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Gabriel Ravier <gabravier@gmail.com>
To: musl@lists.openwall.com, "Rich Felker" <dalias@libc.org>,
	"Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
Subject: Re: [musl] patches for C23
Date: Thu, 4 May 2023 03:09:53 +0200	[thread overview]
Message-ID: <1cf72ea8-f7ca-a869-45f6-7e9bef92a783@gmail.com> (raw)
In-Reply-To: <20230503193325.GZ4163@brightrain.aerifal.cx>

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



  reply	other threads:[~2023-05-04  1:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-01 18:50 Jₑₙₛ Gustedt
2023-05-01 19:24 ` Khem Raj
2023-05-01 19:41 ` Rich Felker
2023-05-02  6:57   ` Jₑₙₛ Gustedt
2023-05-02 13:59     ` Jₑₙₛ Gustedt
2023-05-02 23:20       ` Rich Felker
2023-05-03  0:00         ` Rich Felker
2023-05-03  9:12           ` Jₑₙₛ Gustedt
2023-05-03 14:16             ` Rich Felker
2023-05-03 15:11               ` Jₑₙₛ Gustedt
2023-05-03 17:28                 ` Rich Felker
2023-05-03 18:46                   ` Jₑₙₛ Gustedt
2023-05-03 19:33                     ` Rich Felker
2023-05-04  1:09                       ` Gabriel Ravier [this message]
2023-05-04 14:07                         ` Rich Felker
2023-05-04  6:48                       ` Jₑₙₛ Gustedt
2023-05-04 14:30                         ` Rich Felker
2023-05-04 15:31                           ` enh
2023-05-04 15:53                           ` Jₑₙₛ Gustedt
2023-05-04 16:14                             ` Rich Felker
2023-05-10 14:17                               ` Jₑₙₛ Gustedt
2023-05-10 14:28                             ` [musl] stdbit.h Jₑₙₛ Gustedt
2023-05-04 15:50             ` [musl] patches for C23 Jeffrey Walton
2023-05-04 16:05               ` Rich Felker
2023-05-03  7:13         ` Jₑₙₛ Gustedt
2023-05-03 14:06           ` Rich Felker
2023-05-03 14:26             ` Jₑₙₛ Gustedt
2023-05-03 14:43               ` Rich Felker
2023-05-03 15:26                 ` Jₑₙₛ Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1cf72ea8-f7ca-a869-45f6-7e9bef92a783@gmail.com \
    --to=gabravier@gmail.com \
    --cc=dalias@libc.org \
    --cc=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).