From: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] patches for C23
Date: Thu, 4 May 2023 08:48:46 +0200 [thread overview]
Message-ID: <20230504084846.3f8152d7@inria.fr> (raw)
In-Reply-To: <20230503193325.GZ4163@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 4915 bytes --]
Rich,
on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker <dalias@libc.org>)
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:
> [...]
> [...]
> > > [...]
> > > [...]
> [...]
> [...]
> > >
> > > 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 ::
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2023-05-04 6:49 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
2023-05-04 14:07 ` Rich Felker
2023-05-04 6:48 ` Jₑₙₛ Gustedt [this message]
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=20230504084846.3f8152d7@inria.fr \
--to=jens.gustedt@inria.fr \
--cc=dalias@libc.org \
--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).