From owner-cvs-src@FreeBSD.ORG Wed May 28 17:25:29 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A401065674; Wed, 28 May 2008 17:25:29 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.74]) by mx1.freebsd.org (Postfix) with ESMTP id C07B08FC16; Wed, 28 May 2008 17:25:29 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtp011-bge351000 (asmtp011-bge351000 [10.150.69.74]) by smtpoutm.mac.com (Xserve/smtpout011/MantshX 4.0) with ESMTP id m4SHPTGs012364; Wed, 28 May 2008 10:25:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K1L004IH9QGY140@asmtp011.mac.com>; Wed, 28 May 2008 10:25:29 -0700 (PDT) Message-id: <8B311170-7A48-4121-9EE8-734488D0F35C@mac.com> From: Marcel Moolenaar To: "Bruce M. Simpson" In-reply-to: <483D8B9E.9060909@FreeBSD.org> Date: Wed, 28 May 2008 10:25:27 -0700 References: <200805281641.m4SGf3ix052304@repoman.freebsd.org> <483D8B9E.9060909@FreeBSD.org> X-Mailer: Apple Mail (2.919.2) Cc: cvs-src@FreeBSD.org, Marcel Moolenaar , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include atomic.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 17:25:29 -0000 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... -- Marcel Moolenaar xcllnt@mac.com