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:
>>> 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:
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++.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk