Compile error with PPC

[nicolas danet <nicolas.danet@…>]

I get the error below, compiling on Xcode 2.5 / GCC 4.0 / OS X 10.4.11:

/Users/jeantoto/dev/boost_1_53_0/boost/atomic/detail/gcc-ppc.hpp: In member function 'T boost::atomics::detail::base_atomic<T, int, 4u, Sign>::fetch_add(T, boost::memory_order) volatile [with T = long int, bool Sign = true]': /Users/jeantoto/dev/boost_1_53_0/boost/atomic/detail/gcc-ppc.hpp:1204: error: impossible constraint in 'asm'

1. It is on PPC arch only.
2. Get the same error with Boost-trunk (gcc-ppc.hpp:1211).

#include <boost/atomic.hpp>
    
int main( )
{
    boost::atomic<long> messageCount_(0);
    messageCount_.fetch_add(1, boost::memory_order_relaxed);
}

[timblechmann]

the powerpc-linux-gnu-g++-4.8 cross compiler compiles this for me ... gcc-4.0 is outdated and probably not even supported by apple anymore ... i therefore tend to close it as wontfix ...

[nicolas danet <nicolas.danet@…>]

Boost::atomic is announced to compile on "gcc 4.x: i386, x86_64, ppc32, ppc64, armv5, armv6, alpha" so that's why i created this ticket.

IMHO this support should be cool, related to the purpose of the component ("It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature") but in other hand it may be lots of work and/or mess for few users.

I'm not an expert in assembly and i can not do it myself ; so it's up to you.

[timblechmann]

of course it would be cool, but i neither have the toolchain to test, nor time, nor a personal interest in supporting apple's gcc-4.0

btw, apple's gcc is something else than gcc ... and for me, apple's gcc caused a lot of problems in the past ...

[nicolas danet <nicolas.danet@…>]

Thanks for infos ; I'm newbie in programming and i was not aware of the apple specific implementation of GCC. Sure it is not a very attractive to support an old powerpc-apple-darwin8-g++-4.0.1 and you are certainly right to close this ticket as wontfix. Anyway thanks for replies.

[Andrey Semashev]

Should this be closed as wontfix?

[nicolas.danet@…]

Replying to andysem:

Should this be closed as wontfix?

I think so.