[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2023 08:31:32 -0700
From: enh <enh@...gle.com>
To: musl@...ts.openwall.com
Cc: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Subject: Re: patches for C23
On Thu, May 4, 2023 at 7:31 AM Rich Felker <dalias@...c.org> wrote:
> On Thu, May 04, 2023 at 08:48:46AM +0200, Jₑₙₛ Gustedt wrote:
> > Rich,
> >
> > on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker <dalias@...c.org>)
> > 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
> > > > <dalias@...c.org>) wrote:
> > > >
> > > > > On Wed, May 03, 2023 at 05:11:11PM +0200, Jₑₙₛ 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 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.
> >
> > 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 = 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 <stdckdint.h>
and <stdbit.h> 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, <stdbit.h> 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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
