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?


On 09/26/2011 01:31 PM, James Dennett wrote:
On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeod<amacleod@redhat.com> wrote:

The C++11 memory model asserts that a program containing data races involving *non-atomic* variables has undefined semantics. The compiler is not allowed to introduce any data races into an otherwise correct program.
C++11 specifies data races in terms of properties of the source code.

A conforming implementation may translate that code into something
that races on actual hardware if the race is benign _on that
hardware_.  For example, it might read from a memory address that's
being written to concurrently if it knows that the write cannot
materially affect the value read.  A user's C++ code that attempted to
do so would have undefined behavior, but the C++ compiler is
generating code for some more concrete platform that will likely have
a range of possible behaviors for such races.

I'm only talking about detectable data races, although I didn't clarify that here. We're allowing load races for the most part since they are pretty much benign everywhere. We have to avoid introducing new races with stores though because they can usually be detected.


Andrew


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