This is the mail archive of the 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: PATCH [gcc and libstdc++] for memory barriers in staticinitalization

On Fri, 24 Dec 2004 07:56:29 -0800, "David S. Miller" <> wrote:

> On Fri, 24 Dec 2004 10:29:17 -0500
> Jason Merrill <> 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.


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