The cpp11_thread test fails on my machine for all Cortex-M0 platforms because of missing __atomic_fetch_sub_4. It may be caused by the way the cortex-m0 toolchain is built or the linking order of the libraries, I don't know how to fix it however.

Sounds like I good idea. Moving the __dso_handle to a single location is much cleaner. I am not entirely sure why we need to implement newand delete, can you elaborate that?

Regarding the Cortex-M0, I have only tested the code on the stm32f4discovery boards, hence the whitelist. I will see if I can get my hands on a Cortex-M0 take a look at the error.

@josephnoir
you can try it with make BOARD=yunjia-nrf51822 or make BOARD=stm32f0discovery for example.

I did not actually test new and delete, I just assumed that they would not work properly without a custom implementation. Does GCC/newlib provide any fallbacks for those operators?

If I recall correctly, the __dso_handle is not required on native. (And, I run into: multiple definition of '__dso_handle'.)

Regarding the problem on the Cortex-M0 I found this two threads on launchpad: one and two. It seems we need to implement an alternative atomic header if we want them on these boards.

Or, maybe, they will offer support in the future ...

(An atomic is only used at one point, for the reference count of the thread class. Alternatively we could use a mutex to guard the reference count and remove the dependency ...)

@josephnoir If you can live with using C for the atomics we could change the reference count into an atomic_int_t and use atomic_inc and atomic_dec to modify it.

It does however not solve the problem if any users try to use C++ atomics

@josephnoir Thank you for your Launchpad research!

After reading through the threads I think it might be possible to add implementations of __atomic_xxxxx in case the libc does not provide them.

One question though: Should I define the __atomic_ functions as weak symbols or should they be protected by an #ifdef CORTEXM0?

From the thread on LP it seems like the CM0 newlib or similar will provide these in the future, but currently doesn't.

I will update this PR to provide simple implementations of the GCC builtin atomics.

Opened #3115 for Cortex M0 support.

Updated with __dso_handle defined weak. Fixes linker errors on native

I can live with using an atomic implementation that works for most (or all) devices. If that is using C for atomics, so be it.

However, did I understand your later comments correctly, i.e., #3115 can offer the missing atomic calls to allow the usage of the C++ atomic header (which would be much nicer fix and lead to better C++ support)?

@josephnoir yes, #3115 introduces the helper functions that are necessary to support at least parts of #include <stdatomic.h> on GCC (which is also used by C++11 #include <atomic>)
We can expand on it later if we notice that we need more helpers.

https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary is a not quite up to date page regarding the GCC 4.7 atomic work, it was the best I could find for describing the helper functions (see "list of library routines"). It mentions a couple of other functions in addition to the ones I implemented, but I got your example to compile using only the functions in #3115 . I did not try running it though, I don't have any board with an M0.

Awesome! I can confirm that #3115 allows compiling the cpp11 tests for the samr21-xpro and the example I tested (cpp11_thread) works on the board.

One question though: Should I define the _atomic functions as weak symbols or should they be protected by an #ifdef CORTEXM0?

I would prefer the ifdef solution (even if it is definitely uglier), but the weak symbol is GCC dependent.

I don't have any desire to use dynamic memory in any application right now and I don't have time to test it.

In its current state, this PR adds the rudimentary support necessary for static constructors and virtual functions.

@josephnoir OK to postpone any new and delete tests (and any necessary function implementations) until later and merge this (after the dependencies has been merged) as a step towards proper C++ support?

@gebart Yes, sounds good.

(The thread implementation does use a new at the moment and works on the boards I tested ...)

Links for further reading:

• http://www.webalice.it/fede.tft/cpp_on_microcontrollers_tricks/cpp_on_microcontrollers_tricks.html
• http://elegantinvention.com/blog/information/smaller-binary-size-with-c-on-baremetal-g/

Rebased after #3115 was merged.

@josephnoir OK to squash?

Sorry, I am traveling a lot at the moment. What does the __gnu_cxx stuff do when using clang as a compiler? Otherwise, go ahead.

@josephnoir the __gnu_cxx stuff will be just another namespace and it will even be GC:ed when linking as usual if it is not referenced, so it should not affect compilers/C++ libraries which does not need it. It is only used in certain GCC configurations, but it is such a tiny function that we're just wasting time if we try to exclude it with #ifdef depending on configuration.

rebased after the libfixmath_unittests build problems were fixed in #3470. Waiting for Travis.

Travis is fine. Anyone care to ACK this?

@josephnoir, @BytesGalore ping

ACK

I see an ACK and Travis being green. @gebart, if you wanna squash, go ahead, otherwise just hit the button!