On 05/29/2015 06:18 AM, Ramana Radhakrishnan wrote: > > One of the bits of fallout that I've observed in my testing and that I'm not > sure about what to do is that on *bare-metal* arm-none-eabi targets we still > put out calls to __sync_synchronize on architecture versions that do not have > a > barrier instruction which will result in a link error. > > While it is tempting to take the easy approach of not putting out the call, I > suspect in practice a number of users of the bare-metal tools use these for > their own RTOS's and other micro-OS's. Thus generating barriers at higher > architecture levels and not generating barriers at lower architecture levels > appears to be a bit dangerous especially on architectures where there is > backwards compatibility (i.e. -mcpu=arm7tdmi on standard user code is still > expected to generate code that works on a core that conforms to a later > architecture revision). > > I am considering leaving this in the ARM backend to force people to think what > they want to do about thread safety with statics and C++ on bare-metal > systems. > If they really do not want thread safety they can well add > -fno-threadsafe-statics or provide an appropriate implementation for > __sync_synchronize on their platforms. > > Any thoughts / comments ?
That seems reasonable. It probably warrants some documentation somewhere though. r~
