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,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14304 invoked from network); 4 May 2023 15:32:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 15:32:01 -0000 Received: (qmail 5892 invoked by uid 550); 4 May 2023 15:31:57 -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 5858 invoked from network); 4 May 2023 15:31:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683214305; x=1685806305; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y5f3TjY6BMY8pY8Gl9p96YmqL+szMyDcOWHlKgB764w=; b=YTcI3BI0FazRUkSURMKtpBimFexhO8dqE/JxuonTwdxmfkx2R0bcPIFxkB6u6ZofD3 RO0jhQEAooSNHvMN9WsYdNQhJGTAO1XGt1Lt2YNT93iZ/olsJZx7EN7BL3ewzcJ3lVpP sfc/9pXX6+20ZgTvSmqOhAwRvSge7EnZbGo+/KMykKTr2b508Cg8Z9gXamxZicaFLqbb K3JeHVFRo6WNAHo3hNhnwDxFwER3UhqVrWuHyJNG/JqZHDkYQkKLNaOYkaFv2cEsKj9k N91E/QBkSYVWCORiyy6YnVa+yFfdKSeEkSLmLRwuk08sX7P/wLzR5Udm0pOypr1QDKsy B3Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683214305; x=1685806305; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y5f3TjY6BMY8pY8Gl9p96YmqL+szMyDcOWHlKgB764w=; b=iysacyuIdnyaa+wjOBCba8r9nOX0DTWibHIfl9LXtNkPgFDnxZSchEj+sVZtKlHmHE zPz2lIXg6R8idEJI5MhTyZNmyEes69BCwjk0HWNQsBsKOe/HzcX7f6h3fhRV+VRQwXYK o1SypI2NkL7M9E+yJ8H+ykO1FOgbSdwJ3jl7rUFjMfY06qJBYi9Q4NUwWno1Ud9ci9ao pKN+sulkBCCn81QP7tUrLgcaebn8RzG/5d0zoFxxkVH875QQTzfBcs6qaurzCbm/wzTy IX0EKgTPc2reziJO7/wd/L0V9RtCSDnG537fqzk5dzeIpnWanw/PdOR6rTLC23tERzl+ tyAg== X-Gm-Message-State: AC+VfDzTNBCDhtjyCva4b3mbd3UZxUq/BdpqTZ7eCvRgMKPF/dYw4TI0 6dagT2xSC2A87SKtXTaT80+x5HIfRMk6oDaM9PtO6XXdbshTJnGzFSuVjXFQ X-Google-Smtp-Source: ACHHUZ4w6fu/1nJWQI/j8k1848QvlyzKBuSaDl6qKZsp32keW25GfOKWH/qBnjrfr5NFkd3yQzvOg8Zg0ute9etRjMA= X-Received: by 2002:ac8:5f14:0:b0:3f0:daab:f24f with SMTP id x20-20020ac85f14000000b003f0daabf24fmr5899442qta.68.1683214304763; Thu, 04 May 2023 08:31:44 -0700 (PDT) MIME-Version: 1.0 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> <20230504143052.GB4163@brightrain.aerifal.cx> In-Reply-To: <20230504143052.GB4163@brightrain.aerifal.cx> From: enh Date: Thu, 4 May 2023 08:31:32 -0700 Message-ID: To: musl@lists.openwall.com Cc: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Content-Type: multipart/alternative; boundary="000000000000b7e2ce05fadfde87" Subject: Re: [musl] patches for C23 --000000000000b7e2ce05fadfde87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 4, 2023 at 7:31=E2=80=AFAM Rich Felker wrote: > On Thu, May 04, 2023 at 08:48:46AM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt 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=E2=82=91=E2=82=99=E2=82= =9B 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=E2=82=91=E2=82=99=E2= =82=9B 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 approac= h > > > > 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 =3D 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? the outcome of https://github.com/llvm/llvm-project/issues/62248 was the former, sadly. i was hoping so just send llvm a macro-only and and stay out of it. that should still work for the former, but i'm not sure what to do about the latter. (_apart_ from the fact that it's in ISO C, seems strictly worse than just using __builtin_foo(). even the names are less readable, and having them as external functions seems to defeat the purpose of them existing in the first place. i'm very tempted to just implement them as macros and leave the actual functions as a "you're holding it wrong" case. but probably i'll just wait to see if these ever actually get used first...= ) > 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 > --000000000000b7e2ce05fadfde87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 4, 2023 at 7:31=E2=80=AFA= M Rich Felker <dalias@libc.org>= ; wrote:
On Thu,= May 04, 2023 at 08:48:46AM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gustedt wro= te:
> Rich,
>
> on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker <dalias@libc.org>)
> wrote:
>
> > On Wed, May 03, 2023 at 08:46:56PM +0200, J=E2=82=91=E2=82=99=E2= =82=9B Gustedt wrote:
> > > Rich,
> > >
> > > on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker
> > > <dal= ias@libc.org>) wrote:
> > >=C2=A0 =C2=A0
> > > > On Wed, May 03, 2023 at 05:11:11PM +0200, J=E2=82=91=E2= =82=99=E2=82=9B Gustedt wrote:=C2=A0
> >=C2=A0 [...]=C2=A0
> >=C2=A0 [...]=C2=A0
> > > >=C2=A0 [...]=C2=A0
> > > >=C2=A0 [...]=C2=A0 =C2=A0
> >=C2=A0 [...]=C2=A0
> >=C2=A0 [...]=C2=A0
> > > >
> > > > Again, there are not multiple versions of musl with dif= ferent
> > > > features depending on which compiler was used to compil= e them.
> > > > There is one unified feature set. There are not configu= re-time or
> > > > compile-time decisions about which features to support.= =C2=A0
> > >
> > > This sounds a bit dogmatic=C2=A0
> >
> > 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 versio= ns of
> > > gcc and clang will soon support `va_start` with only one par= ameter
> > > for example. Musl will just be dependent on that compiler fe= ature.=C2=A0
> >
> > 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 obviou= s
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` bein= g 64,
> > > would that be acceptable for you? Or an even more dependent = approach
> > > with special casing architectures where this is available si= nce
> > > always?=C2=A0
> >
> > It's not really "special casing archs where this is avai= lable since
> > always". It's more like the other way around, "not = special casing
> > archs where __int128 is a guaranteed part of the baseline psABI&q= uot;. For
> > those we can just let the default C implementation be used. For t= he
> > 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<= br> > `_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)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return (union u){ .x =3D 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?

the outcome of https://github.com/llvm/llvm-project/issues/62248 was the former, sa= dly. i was hoping so just send llvm a macro-only <stdckdint.h> and &l= t;stdbit.h> and stay out of it. that should still work for the former, b= ut i'm not sure what to do about the latter.

(= _apart_ from the fact that it's in ISO C, <stdbit.h> seems strict= ly worse than just using __builtin_foo(). even the names are less readable,= and having them as external functions seems to defeat the purpose of them = existing in the first place. i'm very tempted to just implement them as= macros and leave the actual functions as a "you're holding it wro= ng" case. but probably i'll just wait to see if these ever actuall= y get used first...)
=C2=A0
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
--000000000000b7e2ce05fadfde87--