From owner-cvs-all@FreeBSD.ORG Thu May 29 18:43:25 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336E31065672; Thu, 29 May 2008 18:43:25 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id ADACA8FC19; Thu, 29 May 2008 18:43:24 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m4TIi7iv020695; Thu, 29 May 2008 14:44:07 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m4TIi7k5020694; Thu, 29 May 2008 14:44:07 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 29 May 2008 14:44:07 -0400 From: David Schultz To: Marcel Moolenaar Message-ID: <20080529184407.GA20640@zim.MIT.EDU> Mail-Followup-To: Marcel Moolenaar , "Bruce M. Simpson" , Marcel Moolenaar , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200805281641.m4SGf3ix052304@repoman.freebsd.org> <483D8B9E.9060909@FreeBSD.org> <8B311170-7A48-4121-9EE8-734488D0F35C@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B311170-7A48-4121-9EE8-734488D0F35C@mac.com> Cc: cvs-src@FreeBSD.ORG, Marcel Moolenaar , "Bruce M. Simpson" , src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/ia64/include atomic.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 18:43:25 -0000 On Wed, May 28, 2008, Marcel Moolenaar wrote: > > On May 28, 2008, at 9:43 AM, Bruce M. Simpson wrote: > > >Marcel Moolenaar wrote: > >>...the cmpxchg instruction was comparing > >> 0x0000000080000000LU to 0xffffffff80000000LU and obviously didn't > >> perform the exchange. > >> ...Subsequent locking requests found rw_state non-zero > >> and the thread in question entered the kernel and block > >>indefinitely. > > > > > >Man, this must have been a total nightmare to track down. > > Yeah. It was 2 puzzles in one. First you need to track down the failure > and then you need to figure out how to work around it... > > >I guess the bigger question is, why was gcc sign-extending a > >constant marked U in the first place? > > My best answer is: because of a bug :-) > > In this case GCC knew the value and as such opened itself up to its own > sign bugs. Normally cmpval is unknown (by virtue of not being constant > or > by virtue of not being able to constant-propagate across functions) and > GCC will perform standard transformations. The standard transformations > can only work with the type of cmpval, which is uint32_t and as such > will > do zero-extension. But if the value is known, optimizations kick in that > normally wouldn't kick in and in. Those optimizations have a tendendency > to focus on the value and not on the type. In this case the constant has > the sign-bit set, so somewhere along the lines sign-extension happened > that shouldn't have happened and it's hard to get the right result in > the > end... I remember from writing fenv.h that there were lots of painful bugs involving gcc on ia64 and inline asms. Generally things would work at -O0, but once you turned on inlining you got bogus code. Then turning on -O2 or -fschedule-insns2 would fix it again.