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++.