This is the mail archive of the
mailing list for the GCC project.
Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- From: Richard Henderson <rth at redhat dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>, Jason Merrill <jason at redhat dot com>, David Edelsohn <dje dot gcc at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jim Wilson <wilson at tuliptree dot org>, Steve Ellcey <sellcey at mips dot com>, Steve Munroe <munroesj at linux dot vnet dot ibm dot com>, Torvald Riegel <triegel at redhat dot com>
- Date: Fri, 29 May 2015 08:41:13 -0700
- Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- Authentication-results: sourceware.org; auth=none
- References: <555F1143 dot 4070606 at foss dot arm dot com> <555F11B6 dot 1070001 at foss dot arm dot com> <555F31CF dot 6060201 at redhat dot com> <CAGWvnykzukDM2aG_QmbeCyOh7+u6xF8snOc13GUHG2RULoQU-g at mail dot gmail dot com> <555F3D09 dot 2070700 at redhat dot com> <555F49FF dot 1070402 at foss dot arm dot com> <555F6911 dot 6030205 at redhat dot com> <5568673A dot 6060007 at foss dot arm dot com>
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.