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=-1.1 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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31206 invoked from network); 3 May 2023 18:47:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 18:47:14 -0000 Received: (qmail 3995 invoked by uid 550); 3 May 2023 18:47:10 -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 3961 invoked from network); 3 May 2023 18:47:09 -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=vdfmGbwIEGuM7SyiP+ZIM7Om6fUwn+zF0n71YWTABQc=; b=jGAoYCNJuDcl+WPE9Tn0p8AOauCxJFv6pHyf04SUGxIOsD8wQB/p+kHI geFMXShv6KkmnsonxCvMVkhNLm+MMSTG43w57cfzaUwiNvvaHpfqqs77A u/aP1iX6ORQm1GGH7ayf+mOHUC4R7WbDOk/ds9SjkRsdI5RGc/fEeVYNs I=; 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,248,1677538800"; d="scan'208";a="55020047" Date: Wed, 3 May 2023 20:46:56 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230503204656.152f59b8@inria.fr> In-Reply-To: <20230503172802.GY4163@brightrain.aerifal.cx> References: <20230501205037.29e42745@inria.fr> <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> 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_/JaruPU+57wCmCwyzrg_wbRM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] patches for C23 --Sig_/JaruPU+57wCmCwyzrg_wbRM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker ) wrote: > On Wed, May 03, 2023 at 05:11:11PM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > Rich, > >=20 > > on Wed, 3 May 2023 10:16:19 -0400 you (Rich Felker > > ) wrote: > > =20 > > > On Wed, May 03, 2023 at 11:12:46AM +0200, J=E2=82=91=E2=82=99=E2=82= =9B Gustedt wrote: =20 > [...] =20 > [...] =20 > > >=20 > > > Yes. We don't require a compiler that has an __int128. =20 > >=20 > > 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. =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. This sounds a bit dogmatic 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. 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) > > 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. =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. Yes, exactly. And one supporting `__int128` and the other that doesn't basically wouldn't interfere. 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 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? 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_/JaruPU+57wCmCwyzrg_wbRM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZFKsIAAKCRAP0+hp2tU3 4tRGAJ9cS4Yqmuoz69LgGqjjbZMuvhKvxQCfRPYS45gpyY9HC8dkdDz5+YyvSC8= =qMR4 -----END PGP SIGNATURE----- --Sig_/JaruPU+57wCmCwyzrg_wbRM--