Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jan 2012 18:30:40 +0000
From:      David Chisnall <theraven@FreeBSD.org>
To:        Ed Schouten <ed@80386.nl>
Cc:        svn-src-head@FreeBSD.org, Lawrence Stewart <lstewart@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, davidxu@FreeBSD.org
Subject:   Re: svn commit: r230201 - head/lib/libc/gen
Message-ID:  <D1C0CAC2-C5C5-4392-954F-C680DC9A66DE@FreeBSD.org>
In-Reply-To: <20120119180949.GU95413@hoeg.nl>
References:  <201201160615.q0G6FE9r019542@svn.freebsd.org> <4F13D43C.2060207@freebsd.org> <4F13D768.10307@gmail.com> <20120119180949.GU95413@hoeg.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Jan 2012, at 18:09, Ed Schouten wrote:

> In the very nearby future (after I switch SPARC64 and MIPS to
> libcompiler_rt), it should be possible to safely use C11's =
<stdatomic.h>
> on all supported architectures. The C11 interface allows any operation
> to be combined with any type of barrier.
>=20
> Maybe we should simply migrate this code to use <stdatomic.h> then?

Currently, that will give worse code if we use gcc 4.2.1, but (I hope!) =
better code if we use clang.  With GCC, we are implementing =
atomic_thread_fence() as __sync_synchronize(), which is a full barrier, =
and ignoring its argument.  It would probably be worth postponing any =
such migration until:

1) Clang is the default compiler, and
2) The bugs in LLVM that cause the back end to fatal error on any =
nontrivial code using atomics are fixed.

David=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D1C0CAC2-C5C5-4392-954F-C680DC9A66DE>