mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] patches for C23
Date: Wed, 3 May 2023 20:46:56 +0200	[thread overview]
Message-ID: <20230503204656.152f59b8@inria.fr> (raw)
In-Reply-To: <20230503172802.GY4163@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

Rich,

on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker <dalias@libc.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@libc.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 ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2023-05-03 18:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-01 18:50 Jₑₙₛ Gustedt
2023-05-01 19:24 ` Khem Raj
2023-05-01 19:41 ` Rich Felker
2023-05-02  6:57   ` Jₑₙₛ Gustedt
2023-05-02 13:59     ` Jₑₙₛ Gustedt
2023-05-02 23:20       ` Rich Felker
2023-05-03  0:00         ` Rich Felker
2023-05-03  9:12           ` Jₑₙₛ Gustedt
2023-05-03 14:16             ` Rich Felker
2023-05-03 15:11               ` Jₑₙₛ Gustedt
2023-05-03 17:28                 ` Rich Felker
2023-05-03 18:46                   ` Jₑₙₛ Gustedt [this message]
2023-05-03 19:33                     ` Rich Felker
2023-05-04  1:09                       ` Gabriel Ravier
2023-05-04 14:07                         ` Rich Felker
2023-05-04  6:48                       ` Jₑₙₛ Gustedt
2023-05-04 14:30                         ` Rich Felker
2023-05-04 15:31                           ` enh
2023-05-04 15:53                           ` Jₑₙₛ Gustedt
2023-05-04 16:14                             ` Rich Felker
2023-05-10 14:17                               ` Jₑₙₛ Gustedt
2023-05-10 14:28                             ` [musl] stdbit.h Jₑₙₛ Gustedt
2023-05-04 15:50             ` [musl] patches for C23 Jeffrey Walton
2023-05-04 16:05               ` Rich Felker
2023-05-03  7:13         ` Jₑₙₛ Gustedt
2023-05-03 14:06           ` Rich Felker
2023-05-03 14:26             ` Jₑₙₛ Gustedt
2023-05-03 14:43               ` Rich Felker
2023-05-03 15:26                 ` Jₑₙₛ Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230503204656.152f59b8@inria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).