This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cxx-mem-model merge [6 of 9] - libstdc++-v3
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: amacleod at redhat dot com
- Cc: bkoz at redhat dot com, hp at axis dot com, joseph at codesourcery dot com, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, rth at redhat dot com
- Date: Fri, 11 Nov 2011 20:04:47 +0100
- Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3
> From: Andrew MacLeod <amacleod@redhat.com>
> Date: Fri, 11 Nov 2011 18:45:11 +0100
> On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
> I think there is also an argument for single threaded-ness vs multi
> threaded. If there is no atomic support and its single threaded, we
> don't really need the lock... and I'm not sure how you can detect the
> change in behaviour if test_and_set and clear just store 1 and 0 rather
> than create alock, then do the store of 1 or 0.
>
> If the target is multithreaded, well, we'll have to go to a lock I
> guess... Are there any multithreaded targets without atomic support?
> ie, is this one?
No, cris-elf is not multithreaded target.
(FWIW, cris-*-linux* and crisv32-*-linux* are, but the lack of
update to the atomicity support for them is a port bug.)
brgds, H-P