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 15531 invoked from network); 4 May 2023 16:05:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 16:05:23 -0000 Received: (qmail 31770 invoked by uid 550); 4 May 2023 16:05:21 -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 30713 invoked from network); 4 May 2023 16:05:20 -0000 Date: Thu, 4 May 2023 12:05:08 -0400 From: Rich Felker To: Jeffrey Walton Cc: musl@lists.openwall.com Message-ID: <20230504160508.GD4163@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 On Thu, May 04, 2023 at 11:50:34AM -0400, Jeffrey Walton wrote: > On Wed, May 3, 2023 at 5:13 AM 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? > > It may be worth mentioning the GCC folks say the test is > __SIZEOF_INT128__ >= 16, and not merely defining __SIZEOF_INT128__.[1] > And __SIZEOF_INT128__ will only show up on 64-bit platforms at the > moment. 32-bit platforms will lack the define. __SIZEOF_INT128__ is necessarily 16 if the type exists. This is a consequence of CHAR_BIT==8 and exact-size integer types not being allowed to have padding. Rich