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.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12155 invoked from network); 4 May 2023 14:31:09 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 14:31:09 -0000 Received: (qmail 30369 invoked by uid 550); 4 May 2023 14:31:06 -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 30337 invoked from network); 4 May 2023 14:31:05 -0000 Date: Thu, 4 May 2023 10:30:53 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230504143052.GB4163@brightrain.aerifal.cx> References: <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> <20230504084846.3f8152d7@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230504084846.3f8152d7@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 On Thu, May 04, 2023 at 08:48:46AM +0200, Jₑₙₛ Gustedt wrote: > 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ₑₙₛ 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: > > [...] > > [...] > > > > [...] > > > > [...] > > [...] > > [...] > > > > > > > > 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 > > ?? Either your statement that "musl will be dependent on that compiler feature" is inaccutate or I'm misunderstanding what you mean. The code in musl does not call va_start wth only one parameter. If you mean "in order to provide a conforming C23 compilation environment for applications, the compiler must support a single-parameter va_start built-in", this is true, but it's obvious that to compile C23 applications you need a C23 compiler (or compiler with at least the subset of C23 that you need). This is the application depending on it, not musl depending on it. > > > 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 ;-) Note that you can use gcc -S to generate the asm, clean up any cruft in it, and commit the output to git, using a function like this: struct int128_s { uint64_t a, b; }; union u { __int128 x; struct int128_s s; }; struct int128_s __pop_arg_int128(va_list *ap) { return (union u){ .x = va_arg(*ap, __int128) }.s; } > 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. See above. > There are the `printf`, `scanf` and the new bit-fiddeling > interfaces. For scanf, no special va_list support is needed. It makes use of the POSIX allowance to read pointer arguments as void *, and just stores via them. All it needs to do is format the int128 in memory and memcpy to the void *. > For the latter the current proposal is to have them > implemented as shallow static inline functions. That would a bit > complicated without compiler support. Do the bit-fiddling interfaces require external function definitions, or are macro-only implementations allowed? In case of the latter, yes, you absolutely can assume a compiler that supports whatever type is being used, since they're compiled by the compiler that is building the application, not the compiler that is building musl. > In all to me this sounds like a substantial effort in implementation > and coordination. What is the way forward, here? I don't think it's actually all that much. The popping thunks can be generated from the above mechanically for all archs. The main remaining code is writing explicit long mul/div for operating on a struct representing int128 in two int64s which can be used in printf and scanf/strto*. The div is only /10, so I think it can be quite compact (vs arbitrary 128-bit division which would be nasty). Rich