Re: [boost] missing __volatile__ tags in sp_counted_base_gcc_xxx.hpp

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-03-13 18:00:46

Howard Hinnant wrote:
> On Mar 13, 2006, at 3:37 PM, Peter Dimov wrote:
>
>> Howard Hinnant wrote:
>>> Hello,
>>>
>>> I've been investigating some failures on Mac OS X, ppc concerning
>>> shared_ptr.  One of the things that has struck me is that in boost/
>>> detail/sp_counted_base_gcc_ppc.hpp, the __asm__ block in
>>> atomic_decrement is decorated with __volatile__, but the __asm__
>>> blocks in atomic_increment and atomic_conditional_increment are not.
>>> The failure I'm seeing disappears when the __volatile__ attribute is
>>> added in the two missing places.
>>
>> This is, I believe, intentional; the increments shouldn't be
>> reorder-sensitive, at least in theory. Why/how does it fail?
>
> I'm seeing (only with inlining/optimizations on) that the reference
> count is not properly incremented.  This is with a single-threaded
> test case.  I haven't fully understood the code differences yet, but
> it appears that code is being reordered across these assembly blocks
> in such a way as to change the logic.  I'm not familiar enough with
> gcc assembly semantics to know if the volatile attribute (on the
> assembly block itself, not any data) is required to make inline
> assembly behave itself.
>
> Again, this is not a multithread issue that I can see, as the
> failures I'm seeing are in single threaded code.

There is a known bug in 4.0:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528

that can have this effect, but it apparently has been fixed in 4.0.1. There 
might be others that the boost test doesn't uncover.

I think that the compiler is not supposed to reorder across __asm__ blocks 
in a way that could change the logic and if such reordering happens it 
should be reported as a bug against g++.