On Fri, 2011-11-11 at 12:45 -0500, Andrew MacLeod wrote:
> On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
> >
> >> bkoz: As relates to the existing problem, how is the legacy support
> >> invoked in compatibility-atomic-c++0x.cc? That has the old style
> >> implementation of atomic_flag with a loc
> From: Andrew MacLeod
> 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 no
> From: Benjamin Kosnik
> Date: Fri, 11 Nov 2011 06:43:29 +0100
> So, all:
>
> config/cpu/*/atomicity.h
And config/cpu/*/atomic_word.h presumably?
> Should go. I'll look in to peeling off this cruft sharpish.
brgds, H-P
On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
bkoz: As relates to the existing problem, how is the legacy support
invoked in compatibility-atomic-c++0x.cc? That has the old style
implementation of atomic_flag with a lock, which would allow this
target to compile... which is another option pe
> > I just realized I may be feeding you an inconsistent
> > configuration, see the atomicity stuff in
> > libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
> > now or what do I need to add for that to work?
> >
>
> You don't need to do anything there. I think that atomicity stuff
>
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 15:44:47 +0100
> >> On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote:
> >>> This (formally a change in the range 181027:181034) got me three
> >>> libstdc++ regressions for cris-elf,
> >> yes, I have a final pending patch which didn't make it to the
On 11/08/2011 12:05 AM, Hans-Peter Nilsson wrote:
So, what DO we do if there is no basic level of atomic
support...
I just realized I may be feeding you an inconsistent
configuration, see the atomicity stuff in
libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
now or what do I ne
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 19:08:26 +0100
> So, what DO we do if there is no basic level of atomic
> support...
I just realized I may be feeding you an inconsistent
configuration, see the atomicity stuff in
libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
now o
On 11/07/2011 12:32 PM, Hans-Peter Nilsson wrote:
From: "Joseph S. Myers"
Date: Mon, 7 Nov 2011 17:24:04 +0100
On Mon, 7 Nov 2011, Andrew MacLeod wrote:
Actually, this target has no lock free support whatsoever? ie, no
compare_and_swap instruction, nor an implementation of sync_lock_test_and_s
> From: "Joseph S. Myers"
> Date: Mon, 7 Nov 2011 17:24:04 +0100
> On Mon, 7 Nov 2011, Andrew MacLeod wrote:
>
> > Actually, this target has no lock free support whatsoever? ie, no
> > compare_and_swap instruction, nor an implementation of
> > sync_lock_test_and_set
> > and sync_lock_release?
On 11/07/2011 11:24 AM, Joseph S. Myers wrote:
On Mon, 7 Nov 2011, Andrew MacLeod wrote:
Actually, this target has no lock free support whatsoever? ie, no
compare_and_swap instruction, nor an implementation of sync_lock_test_and_set
and sync_lock_release?
I think the libstdc++ standard now re
On 11/07/2011 06:44 AM, Andrew MacLeod wrote:
> rth: __sync_lock_test_and_set_1 could be provided by libgcc if the
> OS has hooks in it to provide functionality... How can we tell when
> compiling a C++ program whether that is going to be an unresolved
> external or whether libgcc is going to pro
On Mon, 7 Nov 2011, Andrew MacLeod wrote:
> Actually, this target has no lock free support whatsoever? ie, no
> compare_and_swap instruction, nor an implementation of sync_lock_test_and_set
> and sync_lock_release?
>
> I think the libstdc++ standard now requires the class atomic_flag to be lock
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 15:44:47 +0100
> Actually, this target has no lock free support whatsoever? ie, no
> compare_and_swap instruction, nor an implementation of
> sync_lock_test_and_set and sync_lock_release?
In CRIS versions where such support would make sense: of c
On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote:
This (formally a change in the range 181027:181034) got me three
libstdc++ regressions for cris-elf, which has no "atomic"
support whatsoever (well, not the version represented in
"cris-elf"), so something is amiss at the bottom of the default
p
On 11/07/2011 06:17 AM, Hans-Peter Nilsson wrote:
Sorry, no it didn't help. No additional regressions either
though, but the undef'd reference changed to two:
Excess errors:
/tmp/atreg1/gccobj/cris-elf/libstdc++-v3/include/bits/atomic_base.h:273:
undefined reference to `std::atomic_thread_fen
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 05:25:15 +0100
> On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote:
> >
> > This (formally a change in the range 181027:181034) got me three
> > libstdc++ regressions for cris-elf, which has no "atomic"
> > support whatsoever (well, not the version re
On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote:
This (formally a change in the range 181027:181034) got me three
libstdc++ regressions for cris-elf, which has no "atomic"
support whatsoever (well, not the version represented in
"cris-elf"), so something is amiss at the bottom of the default
pa
> From: Andrew MacLeod
> Date: Fri, 4 Nov 2011 00:50:47 +0100
> These are the changes to libstdc++ to make use of the new atomics. I
> changed the files to use the new atomics, and bkoz did a shuffling of
> the include file layout to better suit the new c++ approach.
>
> previously, libstdc++ p
On 11/04/2011 02:14 PM, Jeff Law wrote:
These are the changes to libstdc++ to make use of the new atomics.
I changed the files to use the new atomics, and bkoz did a
shuffling of the include file layout to better suit the new c++
approach.
previously, libstdc++ provided a locked implementation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 17:50, Andrew MacLeod wrote:
> These are the changes to libstdc++ to make use of the new atomics.
> I changed the files to use the new atomics, and bkoz did a
> shuffling of the include file layout to better suit the new c++
> approach.
>
21 matches
Mail list logo
