On 05/04/16 19:08 +0100, Jonathan Wakely wrote:
On 05/04/16 12:01 +0100, Jonathan Wakely wrote:
Well I guess it's mine, and this is a fairly serious regression (is it
tracked in Bugzilla anywhere?) so the patch is OK for trunk.
This is now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70554
I
On 05/04/16 12:01 +0100, Jonathan Wakely wrote:
Well I guess it's mine, and this is a fairly serious regression (is it
tracked in Bugzilla anywhere?) so the patch is OK for trunk.
This is now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70554
On 21/03/16 17:01 +0100, Thomas Schwinge wrote:
Hi!
On Mon, 21 Mar 2016 15:01:49 +, Jonathan Wakely wrote:
On 21/03/16 13:08 +0100, Thomas Schwinge wrote:
>Per my (admittedly, not in-depth) reading of libstdc++-v3 source code,
>the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combi
Hi!
On Mon, 21 Mar 2016 15:01:49 +, Jonathan Wakely wrote:
> On 21/03/16 13:08 +0100, Thomas Schwinge wrote:
> >Per my (admittedly, not in-depth) reading of libstdc++-v3 source code,
> >the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with
> >the _Atomic_word data type, wh
On 21/03/16 13:08 +0100, Thomas Schwinge wrote:
Per my (admittedly, not in-depth) reading of libstdc++-v3 source code,
the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with
the _Atomic_word data type, which in
libstdc++-v3/doc/xml/manual/concurrency_extensions.xml is described
mics, but not long. But then, only
the short and int results are used to decide on _GLIBCXX_ATOMIC_BUILTINS,
and on the other hand there actually are "typedef long _Atomic_word"
definitions, but long atomics are not explicitly checked for.
OK to commit to following?
commit 1347
