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.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14939 invoked from network); 4 May 2023 15:51:02 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 15:51:02 -0000 Received: (qmail 18209 invoked by uid 550); 4 May 2023 15:50:59 -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 18150 invoked from network); 4 May 2023 15:50:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683215446; x=1685807446; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Xq49iPASt7OmNMKQ9ep8p5hv+WKrQBFzOIraCUzFxck=; b=AyDaKHCrFVy5NY76B34DRLmGqD25xzPbAh5g1ffED1EdhYbfpCFC6y9ezE/8aq0KZT nTc+letISxbWpl/89Otpv/GmpKwZv2oUx6A1DP57HubXHcDGX95dZf7MN295m4tVKvmO 4VUY6/ejrsLjLnffrcwONKdnhaQ/uX2NRejTOys8/81rAB0mm06QifMwAcyZkwNDUTi8 wPySQc/AljWS797GSU1sVx47WCilowZSGi2uTDptC0M1EbD+feC5RntWj0fSJ1IEcV+s b8+7SEUYrXIMRJ02CDJweo4AZ4Nq2bcxouEoMkQ/FsLzfZWKsyVyqp0gikKxluBpES0E CYoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683215446; x=1685807446; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Xq49iPASt7OmNMKQ9ep8p5hv+WKrQBFzOIraCUzFxck=; b=lQs4tHkY6r+fUmfdJYFCevEUAwBARNwJ4Cifo2p+PpFe5aTi2cImuz+Ly4cI0RWM+z 3BvDoeCwmd6Q7bcDBwt32jjw1amjE9afurPSUXpnPIEpkf+O0Nml+EueAFJKtJr2xZD8 IWGxV/Lpxf6ikVxrlwuoplWb0YAJf3yg/tEH6VMTzpmYbQhFZiI/YH9FG1I+B1htFf0S jdPqXTDgR+fznqZ7hYJMly+fKnpVZjroOBm7WU9SCsR8OiWf3FAjrk6meIVwMhWnCfX0 cQ+4i9U0j16gSTwKe/1FbUR1ZS1TLqpvxJFJGYXd2nvK+thHZkrIKlw5kVNzY8cG28+B OENw== X-Gm-Message-State: AC+VfDzpyBvYBk8Nt/ON5xQbpbDENi5uN0z/IenrXcVFw45ylW09vquJ j2vH0+xfErSdeVpq7DyrBAsW2nSidO9MPKSnQJLqjyTIDZI= X-Google-Smtp-Source: ACHHUZ7n6w50nGr/FLFBBr6zNIU9Vh+6IOVxXlJ9HSSjXnfMmvJsJ0V2zBsE7WExDjZlrPovzgv0jdXlLihIrHdmoWg= X-Received: by 2002:a05:6870:51c4:b0:177:a565:a7e1 with SMTP id b4-20020a05687051c400b00177a565a7e1mr1366589oaj.16.1683215446090; Thu, 04 May 2023 08:50:46 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20230503111246.00ba409e@inria.fr> From: Jeffrey Walton Date: Thu, 4 May 2023 11:50:34 -0400 Message-ID: To: musl@lists.openwall.com Cc: Rich Felker Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] patches for C23 On Wed, May 3, 2023 at 5:13=E2=80=AFAM J=E2=82=91=E2=82=99=E2=82=9B 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__ >=3D 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. Jeff [1] 128-bit integer - nonsensical documentation?, https://gcc.gnu.org/legacy-ml/gcc-help/2015-08/msg00176.html