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 28585 invoked from network); 3 May 2023 17:28:18 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 17:28:18 -0000 Received: (qmail 18366 invoked by uid 550); 3 May 2023 17:28:15 -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 18322 invoked from network); 3 May 2023 17:28:14 -0000 Date: Wed, 3 May 2023 13:28:02 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230503171111.15092dbb@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 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: > > > > Language/compiler baseline for building musl is not going to go > > > > up, so this complicates some things, especially implementing the > > > > int128 stuff. This will need pop_arg to call out to an > > > > arch-provided asm function that bypasses the C type system to get > > > > the nonexistent-type argument off the va_list and store it in a > > > > pair of uint64_t. > > > > > > I don't see that. `pop_arg` just uses `va_arg` and that in turn is > > > fixed to `__builtin_va_arg`. The proposed patches assume that if > > > `__SIZEOF_INT128__` is defined by the compiler that then the > > > compiler provides the `__int128` types and knows how to deal with > > > them in `__builtin_va_arg`. Is there anything wrong with that > > > assumtion? > > > > 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. > 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. Rich