cvs commit: src/sys/ia64/include atomic.h

[David Schultz]

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.