This is the mail archive of the gcc@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: should sync builtins be full optimization barriers?

From: Jakub Jelinek <jakub at redhat dot com>
To: Geert Bosch <bosch at adacore dot com>
Cc: Andrew MacLeod <amacleod at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, GCC Mailing List <gcc at gcc dot gnu dot org>, Aldy Hernandez <aldyh at redhat dot com>
Date: Sun, 11 Sep 2011 21:11:47 +0200
Subject: Re: should sync builtins be full optimization barriers?
References: <4E69C942.3090808@gnu.org> <20110909081705.GT2687@tyan-ft48-01.lab.bos.redhat.com> <5F13A1A0-79E5-4733-B543-4A6F6311A247@adacore.com> <4E6CC1E4.5000000@redhat.com> <93C7346D-DC47-4C6B-9755-EF438D82DDEA@adacore.com>
Reply-to: Jakub Jelinek <jakub at redhat dot com>

On Sun, Sep 11, 2011 at 03:00:11PM -0400, Geert Bosch wrote:
> Also, for relaxed order atomic operations we would only need a single
> fence between two accesses (by a thread) to the same atomic object.

I'm not aware of any CPUs that would need any kind of fences for that.
Nor the compiler should need any fences for that, MEMs that may (or even are
known to be aliased) aren't reordered.

	Jakub

Follow-Ups:
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch

References:
- should sync builtins be full optimization barriers?
  - From: Paolo Bonzini
- Re: should sync builtins be full optimization barriers?
  - From: Jakub Jelinek
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch
- Re: should sync builtins be full optimization barriers?
  - From: Andrew MacLeod
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch

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