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: PATCH [gcc and libstdc++] for memory barriers in staticinitalization


On Fri, 24 Dec 2004 11:34:00 -0500
Jason Merrill <jason@redhat.com> wrote:

> On Fri, 24 Dec 2004 07:56:29 -0800, "David S. Miller" <davem@redhat.com> wrote:
> 
> > 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.

Right, for 32-bit programs.

> 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.

Another option is to set TARGET_RELAXED_ORDERING when generating v8plus
or later code.  This still leaves open the issue of what to do in
atomic_word.h, since v8plus code links to v7/v8 libraries.

Or, only set TARGET_RELAXED_ORDERING when generating 64-bit code and
then atomic_word.h's implementation is clear.


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