Re: Bits deduplication: current situation

[Dan Gohman <sunfish@mozilla.com>]

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

On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy <nsz@port70.net> wrote:

> * Rich Felker <dalias@libc.org> [2016-01-25 16:00:05 -0500]:
> > On Mon, Jan 25, 2016 at 11:22:13AM -0800, Dan Gohman wrote:
> > > Concerning stdint.h, there are a few details beyond just 32-bit vs
> 64-bit.
> > > For example, int64_t can be either "long" or "long long" on an LP64
> target.
> > > The difference usually doesn't matter, but there are things which end
> up
> > > noticing, like C++ name mangling and C format-string checking.
> >
> > I'm pretty sure int64_t is long on all LP64 targets we support. Are
> > there others that differ?
>

I'm working on an architecture which does, though there's no musl support
for it currently.

note that the patch is wrong for all released versions of gcc (<=5)
> because the *fast types are different on musl vs glibc on 64bit arches.
> (fwiw newlib defines these types in yet another way)
>

> this is not visible in the libc abi but matters for third-party
> code compiled against musl headers and those should be abi
> compat no matter what compiler you used.
>
> (with gcc the difference matters if you use the gcc provided stdatomic.h
> or use the gfortran c ffi, but then you probably built a gcc
> with musl support anyway and then the types are consistent.)
>

Ah, I was unaware that musl and glibc differ here. I agree that that
complicates the patch I had envisioned, so I'll drop the idea for now.

Thanks,

Dan

[-- Attachment #2: Type: text/html, Size: 2420 bytes --]