Date: Wed, 28 May 2008 10:25:27 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Marcel Moolenaar <marcel@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include atomic.h Message-ID: <8B311170-7A48-4121-9EE8-734488D0F35C@mac.com> In-Reply-To: <483D8B9E.9060909@FreeBSD.org> References: <200805281641.m4SGf3ix052304@repoman.freebsd.org> <483D8B9E.9060909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8B311170-7A48-4121-9EE8-734488D0F35C>