This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386 __atomic_compare_exchange_n not found
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: Deng Hengyi <wei dot a dot yang at gmail dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, gcc <gcc at gcc dot gnu dot org>, Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Date: Fri, 9 Aug 2013 09:59:13 -0700
- Subject: Re: i386 __atomic_compare_exchange_n not found
- References: <E56937CF-71B9-4174-8129-B258318A36A8 at gmail dot com> <CAH6eHdRJAbxhqzkxbC0uPyg29yecv3r8vq4277hSDP8z=h_EFw at mail dot gmail dot com> <C0E7F57A-AC3B-4A63-9230-88C927A2C4D2 at gmail dot com> <CAH6eHdTB_jDT_6V__pDP6YfKBRadgnrkiz=imwerodj5xETOaw at mail dot gmail dot com> <50EADE7C-2A5D-4109-8688-41CDF4D80998 at gmail dot com> <520512B1 dot 5050800 at oarcorp dot com> <093B8529-E9C6-4E06-B671-7C75FD28C2E7 at gmail dot com> <52051797 dot 9020808 at oarcorp dot com>
On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote:
> On 8/9/2013 11:05 AM, Deng Hengyi wrote:
> > Hi Joel,
> >
> > I have done a test, it seems that '-march=i386' does not provide "__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' can find the '__atomic_compare_exchange_n' function.
> Look in the source for that methods on x86 and see what instruction
> it used. If it only got added in i486, then we have to figure out
> something for i386. If it was an oversight and the instruction is
> on an i386, we fix the code.
The i386 architecture lacks atomic compare instructions, to the point
where libstdc++ can't be built with that architecture (correct and
efficient atomic operations are vital important for libstdc++, andon i386
it can't be done).
The worry is that if you add "atomic" operations that don't lock for the
i386 architecture, you've screwed anyone who decides to build their
application for i386 hoping for maximum portability, but winds up with
locks that don't lock.
You could perhaps handle that for RTEMS by providing these functions in a
library, but users need to understand this issue, because improper locks
are tough to debug.