From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9198 Path: news.gmane.org!not-for-mail From: Dan Gohman Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Mon, 25 Jan 2016 21:03:54 -0800 Message-ID: References: <20160125035925.GA2288@brightrain.aerifal.cx> <20160125210005.GC238@brightrain.aerifal.cx> <20160125213255.GK9621@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114e4e5abafdfc052a359c74 X-Trace: ger.gmane.org 1453784650 13612 80.91.229.3 (26 Jan 2016 05:04:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 05:04:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9211-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 26 06:04:10 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aNvnW-0007S6-5p for gllmg-musl@m.gmane.org; Tue, 26 Jan 2016 06:04:10 +0100 Original-Received: (qmail 27962 invoked by uid 550); 26 Jan 2016 05:04:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 27941 invoked from network); 26 Jan 2016 05:04:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6z5tjXlPdaa2dOXOKAnXahT6451P1e0a+0jGT1G/aZA=; b=SDqKHOeZYnRfzpDAR2WkGX7869j6eLS8UR5c6FBMarWehn8NWAr3wLgk2wOASwnxyQ 6CHoxgm97++o0xM2V/ofKrlD2iFc0dz9leYMuPit6HiXdN5OFRQar/D0jTS6OAZUzKV3 r+9r/HNKvFpgk+N8AhmJAznh2x0p3kryoz1swpcRzPh2riffQhEcbM5ltzS5p4v1c+Lq eair+SpykAS8tyXn7uR2lvfPvt3f+eDrlNK5HzTEIwFqIzhVFLv1PmLm6PJ32vLK7ek4 q6bSn+Kc7oUwvJXn1TuqeW2ezZjRRBeV+UcJjq1KaByVnLEyx8qvHGULmU9wrDxjHuMs Lnyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6z5tjXlPdaa2dOXOKAnXahT6451P1e0a+0jGT1G/aZA=; b=K31muoImzkC87/q0SEjQNmR85RM+tDOMaKzK8+YPvCAG0GZGhqK04TV4ij5vuw8ju1 hmgMxOiJfjT80y5BA5UptIdO6WKLtXculAoDjxOQCM1YnjDGAWL90alGhVYdfA43eMYJ sq4w0WSt72yHPId/LIJGBWxRv9AWcqYKB7YkzmwNfkKT7Lt4NURr0VWYdxA8k8ACNYx5 Y+DdW9d5qmwBjkPOoa/5HKViD0CUclL0cdYkCXte5v6RBB+7iw+Z0HRXG24rBBPOadB9 Xm3VgIqwspz6c7vjpMymmS5HmSNY5MfNW53OYkIKlITQZoIXBO0z+GFiEVlXHu86ZErH MunA== X-Gm-Message-State: AG10YORdiwboX/ySxNC3zlzcTu+taG1eSziYT8TUohM5iyy0/evktAKwFmoAcpa8i/Wkx7cMVSSOZc4Mv39Bh9R4 X-Received: by 10.13.216.196 with SMTP id a187mr10068534ywe.312.1453784634669; Mon, 25 Jan 2016 21:03:54 -0800 (PST) In-Reply-To: <20160125213255.GK9621@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:9198 Archived-At: --001a114e4e5abafdfc052a359c74 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy wrote: > * Rich Felker [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 --001a114e4e5abafdfc052a359c74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 v= s 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 w= hich 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. Ar= e
> there others that differ?

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

note that the patch is wrong for all released versions of gcc (<= =3D5)
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 t= hat musl and glibc differ here. I agree that that complicates the patch I h= ad envisioned, so I'll drop the idea for now.

Thanks,

Dan

--001a114e4e5abafdfc052a359c74--