From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/896 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: A little more progress today with clang/LLVM Date: Mon, 21 May 2012 22:53:06 -0400 Message-ID: <20120522025306.GR163@brightrain.aerifal.cx> References: <6099278.PLLg0Rc9Yf@main.pennware.com> <20120522015935.GQ163@brightrain.aerifal.cx> <2233705.A3NXMro2gt@main.pennware.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1337655509 30894 80.91.229.3 (22 May 2012 02:58:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 May 2012 02:58:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-897-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 22 04:58:28 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SWfIl-0005RY-7e for gllmg-musl@plane.gmane.org; Tue, 22 May 2012 04:58:23 +0200 Original-Received: (qmail 18087 invoked by uid 550); 22 May 2012 02:58:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18079 invoked from network); 22 May 2012 02:58:22 -0000 Content-Disposition: inline In-Reply-To: <2233705.A3NXMro2gt@main.pennware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:896 Archived-At: On Mon, May 21, 2012 at 09:35:59PM -0500, Richard Pennington wrote: > I'll send you the list. The only one that looked sort of bad to me was the out > of bounds array reference. It was on the x86_64 in the pthread_barrier_t > access. clang complained about referencing __p[4], which is out of bounds. > That code is a little cryptic to me right now, since I'm a newbi. ;-) Thanks! Indeed, that's broken. I must not have noticed since I'm on x86 (32-bit). The situation with the definition of these types is unfortunate and I might eventually change it; basically, to avoid leaking implementation details in the public headers, and to avoid having to change the bits headers for all archs if I change the way these primitives work, the public headers just have a union with ints and pointers matching the ABI's size for the type, and pthread_impl.h has macros that map fields into these slots in such a way that the mapping works on both 32- and 64-bit systems. Fixing now... Rich