This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/3] Improve ARM atomic performance for malloc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 7 Oct 2014 16:57:13 +0000
- Subject: Re: [PATCH 0/3] Improve ARM atomic performance for malloc
- Authentication-results: sourceware.org; auth=none
- References: <1412349086-11473-1-git-send-email-will dot newton at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1410031625330 dot 14538 at digraph dot polyomino dot org dot uk> <1412602305 dot 30642 dot 47 dot camel at triegel dot csb> <CANu=DmhPzzN_YKTE9z7mkoAN=zjS-MLRbL93B6C1Y43E4CZg2A at mail dot gmail dot com> <1412691494 dot 30642 dot 104 dot camel at triegel dot csb>
On Tue, 7 Oct 2014, Torvald Riegel wrote:
> What I do need though is consensus from the community that the move
> towards C11 is fine, and feedback on any patches for that.
I think moving towards C11 atomics is desirable, provided that
architectures can still provide their own implementations of atomic
operations in the cases where direct use of __atomic_* would not be
expanded inline or might otherwise be problematic or suboptimal, and can
still control what size operands atomic operations are applied to (so that
any attempt to use atomic operations on arguments other than 32-bit, or
64-bit on 64-bit platforms, can continue to produce obvious compile or
link errors rather than possibly non-obvious references to libgcc).
I'd be happy with requiring GCC >= 4.7 to build glibc, which might reduce
the need for architecture-specific code in some cases, but there may not
yet be consensus for requiring something later than 4.6.
--
Joseph S. Myers
joseph@codesourcery.com