[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230503204656.152f59b8@inria.fr>
Date: Wed, 3 May 2023 20:46:56 +0200
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: patches for C23
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:
> > Rich,
> >
> > on Wed, 3 May 2023 10:16:19 -0400 you (Rich Felker
> > <dalias@...c.org>) 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 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.
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)
> > 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.
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
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?
Thanks
Jₑₙₛ
--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" 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.
