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

[Marcel Moolenaar]

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 at mac.com