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.7 required=5.0 tests=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 838 invoked from network); 3 May 2023 19:33:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 19:33:43 -0000 Received: (qmail 32658 invoked by uid 550); 3 May 2023 19:33:40 -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 32621 invoked from network); 3 May 2023 19:33:39 -0000 Date: Wed, 3 May 2023 15:33:26 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230503204656.152f59b8@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 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 ) > 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 > > > ) 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. > 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