This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH [gcc and libstdc++] for memory barriers in staticinitalization
On Fri, 24 Dec 2004 07:56:29 -0800, "David S. Miller" <davem@redhat.com> wrote:
> On Fri, 24 Dec 2004 10:29:17 -0500
> Jason Merrill <jason@redhat.com> wrote:
>
>> Good to know. So do you think the SPARC port should define the macros or
>> not?
>
> To be absolutely safe, probably yes, and then you're in a real pickle wrt.
> implementing the atomic_word.h header file. :-)
>
> The problem is that you can't emit the "membar #foo" memory barrier
> instructions unless we're generating code where we know we will execute
> on a v9 processor. Yet, since v7/v8 programs execute on v9 processors
> you will need the memory barriers there somehow.
Well, we could just use them in sparcv9/sparc64 configurations.
> If you don't define the macros, things will work on all current
> systems I am aware of which provide effectively TSO semantics
> to userland in one way or another. But some system may break
> one day on Ultra-I/II/IIi chips if RMO is used in userland at
> some point.
My impression has been that it's unlikely that RMO will be used in userland
because of the legacy v7/v8 programs which might break as a result.
One option might be to define TARGET_RELAXED_ORDERING for the sparc, and
not worry about libstdc++ for now; if it were to become necessary to
support RMO code, we could then just change the library without having to
rebuild user code.
Jason