[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230504160508.GD4163@brightrain.aerifal.cx>
Date: Thu, 4 May 2023 12:05:08 -0400
From: Rich Felker <dalias@...c.org>
To: Jeffrey Walton <noloader@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: patches for C23
On Thu, May 04, 2023 at 11:50:34AM -0400, Jeffrey Walton wrote:
> On Wed, May 3, 2023 at 5:13 AM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> wrote:
> >
> > [...]
> > > Language/compiler baseline for building musl is not going to go up, so
> > > this complicates some things, especially implementing the int128
> > > stuff. This will need pop_arg to call out to an arch-provided asm
> > > function that bypasses the C type system to get the nonexistent-type
> > > argument off the va_list and store it in a pair of uint64_t.
> >
> > I don't see that. `pop_arg` just uses `va_arg` and that in turn is
> > fixed to `__builtin_va_arg`. The proposed patches assume that if
> > `__SIZEOF_INT128__` is defined by the compiler that then the compiler
> > provides the `__int128` types and knows how to deal with them in
> > `__builtin_va_arg`. Is there anything wrong with that assumtion?
>
> It may be worth mentioning the GCC folks say the test is
> __SIZEOF_INT128__ >= 16, and not merely defining __SIZEOF_INT128__.[1]
> And __SIZEOF_INT128__ will only show up on 64-bit platforms at the
> moment. 32-bit platforms will lack the define.
__SIZEOF_INT128__ is necessarily 16 if the type exists. This is a
consequence of CHAR_BIT==8 and exact-size integer types not being
allowed to have padding.
Rich
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.
