[Boost-bugs] [Boost C++ Libraries] #7141: smart_ptr sp_has_sync.hpp should use gcc builtin atomics when available on ARM

Subject: [Boost-bugs] [Boost C++ Libraries] #7141: smart_ptr sp_has_sync.hpp should use gcc builtin atomics when available on ARM
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-07-17 11:27:36

#7141: smart_ptr sp_has_sync.hpp should use gcc builtin atomics when available on
ARM
-----------------------+----------------------------------------------------
 Reporter:  anonymous  |        Type:  Bugs            
   Status:  new        |   Milestone:  To Be Determined
Component:  None       |     Version:  Boost 1.51.0    
 Severity:  Problem    |    Keywords:                  
-----------------------+----------------------------------------------------
 I am the lucky owner of a Raspberry Pi, and I have been trying to compile
 some code that uses boost shared_ptr on it (with the Raspbian armhf distro
 with boost 1.49 and gcc 4.6.3).

 I get a lot of "Warning: swp{b} use is deprecated for this architecture",
 some of which originate from spinlock_arm_gcc.hpp.

 I realized that this was fixed in 1.50, but after a bit of looking around
 I realized that gcc 4.6.3 actually has support for the builtin atomics on
 this platform, so that sp_has_sync.hpp should make smart_ptr use them
 instead of trying the assembler stuff in spinlock_arm_gcc.hpp.

 So I propose the following fix to sp_has_sync.hpp:

 {{{
 #define BOOST_SP_HAS_SYNC

 + #if !defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4)
 +
   #if defined( __arm__ )  || defined( __armel__ )
   #undef BOOST_SP_HAS_SYNC
   #endif

 + #endif // __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
 +
   #if defined( __hppa ) || defined( __hppa__ )
   #undef BOOST_SP_HAS_SYNC
   #endif
 }}}

 I maybe more of the platforms can check for the builtins, but I leave that
 to those who know more about them... Also maybe the ..._SWAP_8 would have
 to be used for some of them instead?

 Of course I know that the !__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 is actually
 not defined for all gcc versions where the builtins are available, but
 here we at least will use them when that symbol is defined, rather than
 not at all.

 I have written a similar ticket #7140 for boost asio, which suffers a
 similar problem.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7141>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.