From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 27713 invoked from network); 4 May 2023 06:49:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 06:49:03 -0000 Received: (qmail 28227 invoked by uid 550); 4 May 2023 06:49:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28189 invoked from network); 4 May 2023 06:49:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=nR+1Gc9NKLnsTRNuZ4Jd4KUnUUtYh6BuAG9NBEQ8BwU=; b=u3Z004D03JFEXFhe1bJnTvfYovLdTc8Xm3sH85ptt87BqMOtrlGYI0bE /c5C+NSvjxpzQcCXnTB3kmuPBbD5r28o+DZl1lQoToeg+OW4eOoeFmXla Sx5iaD7OKUFs+Gny32UU2nkMWpd/Vwleoy/CuqHlOs0hCDi6bliusatB1 A=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.99,249,1677538800"; d="scan'208";a="55056824" Date: Thu, 4 May 2023 08:48:46 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230504084846.3f8152d7@inria.fr> In-Reply-To: <20230503193325.GZ4163@brightrain.aerifal.cx> References: <20230501194121.GS4163@brightrain.aerifal.cx> <20230502085740.23ff20d5@inria.fr> <20230502155903.30bee099@inria.fr> <20230502232009.GT4163@brightrain.aerifal.cx> <20230503000045.GU4163@brightrain.aerifal.cx> <20230503111246.00ba409e@inria.fr> <20230503141619.GW4163@brightrain.aerifal.cx> <20230503171111.15092dbb@inria.fr> <20230503172802.GY4163@brightrain.aerifal.cx> <20230503204656.152f59b8@inria.fr> <20230503193325.GZ4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/t9Gsf0mUBC9Ig9XyE1WjZ2R"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] patches for C23 --Sig_/t9Gsf0mUBC9Ig9XyE1WjZ2R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker ) wrote: > On Wed, May 03, 2023 at 08:46:56PM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > Rich, > >=20 > > on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker > > ) wrote: > > =20 > > > On Wed, May 03, 2023 at 05:11:11PM +0200, J=E2=82=91=E2=82=99=E2=82= =9B Gustedt wrote: =20 > [...] =20 > [...] =20 > > > [...] =20 > > > [...] =20 > [...] =20 > [...] =20 > > >=20 > > > 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. =20 > >=20 > > This sounds a bit dogmatic =20 >=20 > Yes, it's one of the core principles of musl: that we don't have > build-time-selectable feature-set like uclibc did. >=20 > > 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. =20 >=20 > 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. >=20 > > 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) =20 >=20 > Decimal float math library will likely be left to a third-party > library implementation. >=20 > 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. > [...] =20 > > >=20 > > > 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. =20 > >=20 > > Yes, exactly. And one supporting `__int128` and the other that > > doesn't basically wouldn't interfere. =20 >=20 > 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. >=20 > > 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 =20 >=20 > We also support pcc, cparser+libfirm, etc. on archs they support. Not > just gcc. And gcc back to 3.x. >=20 > > 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? =20 >=20 > 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=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/t9Gsf0mUBC9Ig9XyE1WjZ2R Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZFNVTgAKCRAP0+hp2tU3 4kMeAKCLrHU0DQmod/7WebbpupigSjbq4gCfeGqqV60KtvsXVTw3Mg8z4juB/MU= =DJBi -----END PGP SIGNATURE----- --Sig_/t9Gsf0mUBC9Ig9XyE1WjZ2R--