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