From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2005-12-12 15:07:13
Peter Dimov wrote:
>Ben Hutchings wrote:
>
>
>>David M Garza wrote:
>>
>>
>>
>>>gdb's stack trace says:
>>>
>>>#0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4)
>>> at sp_counted_base_gcc_ia64.hpp:38
>>>
>>>
>>>
>>>
>>Since gdb is printing the pointers as 32-bit values, and pw is not
>>64-bit-aligned, it appears that your compiler is using the ILP32
>>convention (32-bit int, long and pointer types). I assumed the LP64
>>convention (64-bit long and pointer types, 32-bit int) when writing
>>the assembly-language code in sp_counted_base_gcc_ia64.hpp because I
>>wasn't aware that other conventions were in use on IA64. If the C++
>>code is compiled with an ILP32 convention then the assembly-language
>>code will be completely broken. I may be able to adjust the code to
>>work to detect the model at compile time and use 32-bit memory
>>accesses if appropriate.
>>
>>
>
>Another option is to just switch to 'int' and 32-bit accesses (as we did for
>PPC64 IIRC.)
>
>
Yes, that's another possibility, but it breaks binary compatibility -
surely a black mark against a bug fix? - and I would expect 32-bit
accesses to be a little less efficient. It's fairly easy to select at
compile time, in any case. I'm attaching a patch against Boost CVS HEAD
that should make it work with both 32-bit and 64-bit longs. Could you
test this on HP-UX, David?
Ben.
Index: boost/detail/sp_counted_base_gcc_ia64.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/detail/sp_counted_base_gcc_ia64.hpp,v
retrieving revision 1.2
diff -u -r1.2 sp_counted_base_gcc_ia64.hpp
--- boost/detail/sp_counted_base_gcc_ia64.hpp 18 May 2005 20:10:01 -0000 1.2
+++ boost/detail/sp_counted_base_gcc_ia64.hpp 12 Dec 2005 20:00:24 -0000
@@ -16,7 +16,9 @@
// Lock-free algorithm by Alexander Terekhov
//
+#include <climits>
#include <typeinfo>
+#include <boost/static_assert.hpp>
namespace boost
{
@@ -24,6 +26,17 @@
namespace detail
{
+namespace sp_counted_base_conditions
+{
+#if LONG_MAX == 2147483647
+BOOST_STATIC_ASSERT(sizeof(long) == 4);
+#define BOOST_DETAIL_ASM_LONG "4"
+#else
+BOOST_STATIC_ASSERT(sizeof(long) == 8);
+#define BOOST_DETAIL_ASM_LONG "8"
+#endif
+}
+
inline void atomic_increment( long * pw )
{
// ++*pw;
@@ -33,9 +46,9 @@
// No barrier is required here but fetchadd always has an acquire or
// release barrier associated with it. We choose release as it should be
// cheaper.
- __asm__ ("fetchadd8.rel %0=[%2],1" :
- "=r"(tmp), "=m"(*pw) :
- "r"(pw));
+ __asm__ ("fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],1" :
+ "=r"(tmp), "=m"(*pw) :
+ "r"(pw));
}
inline long atomic_decrement( long * pw )
@@ -44,9 +57,9 @@
long rv;
- __asm__ (" fetchadd8.rel %0=[%2],-1 ;; \n"
- " cmp.eq p7,p0=1,%0 ;; \n"
- "(p7) ld8.acq %0=[%2] " :
+ __asm__ (" fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],-1 ;; \n"
+ " cmp.eq p7,p0=1,%0 ;; \n"
+ "(p7) ld"BOOST_DETAIL_ASM_LONG".acq %0=[%2] " :
"=&r"(rv), "=m"(*pw) :
"r"(pw) :
"p7");
@@ -61,19 +74,19 @@
long rv, tmp, tmp2;
- __asm__ ("0: ld8 %0=[%4] ;; \n"
- " cmp.eq p7,p0=0,%0 ;; \n"
- "(p7) br.cond.spnt 1f \n"
- " mov ar.ccv=%0 \n"
- " add %1=1,%0 ;; \n"
- " cmpxchg8.acq %2=[%4],%1,ar.ccv ;; \n"
- " cmp.ne p7,p0=%0,%2 ;; \n"
- "(p7) br.cond.spnt 0b \n"
- " mov %0=%1 ;; \n"
- "1:" :
- "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) :
- "r"(pw) :
- "ar.ccv", "p7");
+ __asm__ ("0: ld"BOOST_DETAIL_ASM_LONG" %0=[%4] ;; \n"
+ " cmp.eq p7,p0=0,%0 ;; \n"
+ "(p7) br.cond.spnt 1f \n"
+ " mov ar.ccv=%0 \n"
+ " add %1=1,%0 ;; \n"
+ " cmpxchg"BOOST_DETAIL_ASM_LONG".acq %2=[%4],%1,ar.ccv ;; \n"
+ " cmp.ne p7,p0=%0,%2 ;; \n"
+ "(p7) br.cond.spnt 0b \n"
+ " mov %0=%1 ;; \n"
+ "1:" :
+ "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) :
+ "r"(pw) :
+ "ar.ccv", "p7");
return rv;
}