This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]