On Fri, May 29, 2015 at 9:18 AM, Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> wrote:
> - Turns build_atomic_load into build_atomic_load_byte in order > to do an atomic load of 1 byte instead of a full word atomic load. > - Restructures get_guard_cond to decide whether to use an atomic load > or a standard load depending on whether code generated will be in > a multi-threaded context or not. > - Adjusts all callers of get_guard_cond accordingly. > > 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 ? > > regards > Ramana > > gcc/cp/ChangeLog: > > 2015-05-29 Ramana Radhakrishnan <ramana.radhakrish...@arm.com> > > PR c++/66192 > * cp-tree.h (get_guard_cond): Adjust declaration > * decl.c (expand_static_init): Use atomic load acquire > and adjust call to get_guard_cond. > * decl2.c (build_atomic_load_byte): New function. > (get_guard_cond): Handle thread_safety. > (one_static_initialization_or_destruction): Adjust call to > get_guard_cond. > > gcc/ChangeLog: > > 2015-05-29 Ramana Radhakrishnan <ramana.radhakrish...@arm.com> > > > PR c++/66192 > * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise. > * config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise. > * config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise. > * config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise. > * config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise. > * config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise. > * config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise. > * doc/tm.texi: Regenerate. > * doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete. > * target.def (TARGET_RELAXED_ORDERING): Delete. Bootstrap on PPC64 BE and LE Linux successful. The generated code looks like what we expect and much better than the current code generation. Thanks, David
