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>