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=-2.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13955 invoked from network); 4 May 2023 01:10:11 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 01:10:11 -0000 Received: (qmail 27705 invoked by uid 550); 4 May 2023 01:10:08 -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 27667 invoked from network); 4 May 2023 01:10:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683162596; x=1685754596; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=a4kCk8x9Mjurcmv6LI7ZQYLc/k5X4kEd0GCI5Z9jUZ0=; b=GhZHjCTjdOfE4v0PzxPtjqXDvteCqDgbbT2+fCIL0xkA2CHZJTBZe+IWYk99kbm10H dpkpXlPlH7vQ2nzAoozxts2GYX44RmEzhtL8Ke8z+z4iK/HiAvN7+TxdKns5SYMKZ5Z3 Fo7YE+aHz0As6DdGhkLGPBIimmYpLDyEs0TiWQU4z+mRj9lPAhQPY6JBbxNsZumCqZ5U LEtQEkYqdEhj+TYPXRtAp1N4w+mA+NBByyql82wBS7lLD58+qDYtg4VQc4b8P6WB+XmB iSg4VMAlrpmJaxjruIwf8ORTUAX5ZGxOUnAVfS3F1RrW31Yni9VbHAfY3UOuRQjIEZ0t WRzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683162596; x=1685754596; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a4kCk8x9Mjurcmv6LI7ZQYLc/k5X4kEd0GCI5Z9jUZ0=; b=X/skxGvMp+5VmeHUOUZdZUsVLheG8SO765jSiePoxp90D62tk4v1qE3/YcQks3dbjp EXifUaNJbsGWm5bm1HHVDgXBv6REdjPaTqFD3vIJ1GdgslTeR7vN8oxPsebdYb0h90K3 PBZay6nnQxvdJUfIJMaPBU9m41hYNfMSJdei/hPbi8VLchkX+L4FsWB4ZMQhcgORADMv S/k1jIVO7igwPy8llZZ4Y1lAnr/fJ2BBKv3ZJ8i30z3lX0SMAoJxHUZH0INeaum+ov26 obCaHSXpTYO1wO77BGcaYemz6/Xx/VdqrpVgA+Ypx339Mb4MqJaC3XkwCtYXhDiAzDML IYOQ== X-Gm-Message-State: AC+VfDyjgER3d+lQ6nxbhIgJK0ZKjRu9ysy2y6zqAIh9Rv5rWpsLfbeI EyXrrBvRdiyD17zFpYMSRplWWRaFHJxbDw== X-Google-Smtp-Source: ACHHUZ7aab43hQfY3FE3flsqpKn0XHGcPfr/tXwznN+sbYpr/zszW1QjTYubuiCdjG/XXIq/wOArcw== X-Received: by 2002:adf:fa4a:0:b0:306:3814:e323 with SMTP id y10-20020adffa4a000000b003063814e323mr1210286wrr.56.1683162595726; Wed, 03 May 2023 18:09:55 -0700 (PDT) Message-ID: <1cf72ea8-f7ca-a869-45f6-7e9bef92a783@gmail.com> Date: Thu, 4 May 2023 03:09:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: musl@lists.openwall.com, Rich Felker , =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= 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> <20230503193325.GZ4163@brightrain.aerifal.cx> Content-Language: en-US From: Gabriel Ravier In-Reply-To: <20230503193325.GZ4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] patches for C23 On 5/3/23 21:33, 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: >>>> 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. GCC 3.x ??? I understand wanting backwards compatibility but compiler versions from barely after the turn of the century seem like a bit far, I guess it's admirable that musl works with versions of software that are older than I am, but at some point I have to wonder if even a single person in the world actually finds it useful to be able to build musl with GCC 3 in 2023... > >> 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