Jonathan Wakely | 23 Apr 12:48 2015
Picon

map<const T, const U> is assignable even though pair<const T, const U> is not

Marshall Clow sent me this problem:

On 22 April 2015 at 21:49, Marshall Clow wrote:
> The following code fails to compile w/libc++, but succeeds with
> libstdc++.
>
> #include <map>
>
> int main () {
> std::map<const int, const int> foo1, foo2;
> foo2 = foo1;
> }
>
> assigning a allocator-aware container requires that the value type
> be
> CopyAssignable, which pair<const int, const int> is definitely not.
>

I think this is a consequence of our optimization to recycle nodes on
assignment, which runs a destructor and then constructs a new element
with placement new, so it doesn't actually do any assignments.

The example violates the preconditions on the assignment, so it's
undefined behaviour, but it's a bit surprising that it Just Works.

Do we want to make this type non-CopyAssignable?

Jonathan Wakely | 21 Apr 12:27 2015
Picon

[patch] Document effects of -std=c++14 and -std=c++03 in libstdc++ manual

A small doc patch that could also go to the 4.9 and 5 branches.

Committed only to trunk for now.

Attachment (patch.txt): text/x-patch, 2954 bytes
Jonathan Wakely | 20 Apr 13:08 2015
Picon

[patch] Improve libstdc++ documentation on using atomics.

Currently we don't mention libatomic anywhere in the libstdc++ manual,
even though it might be needed for std::atomic.

This fixes that and makes a few other drive-by improvements.

Committed to trunk. This would be suitable for all active branches,
so I might backport it once the gcc-5-branch opens.

Attachment (patch.txt): text/x-patch, 11 KiB
Daniel Langr | 20 Apr 09:40 2015
Picon

Poor speedup with parallel quick sort algorithms

I cannot get speedup higher than 2 with in-place sorting algorithms (quick sort and balanced quick sort)
from the parallel implementation of libstdc++ (parallel mode). I have tried to run the code on many
different systems consisting of from 16 to 24 cores. I have also tried GNU and Intel C++ compilers with same
results. The speedup around 2 is the same for any number of cores between 2 and max.
On the contrary, multi-way merge sort scales well (speedup around 10 using 16 threads on 16 cores machine).
According to J. Singler's presentation "The GNU libstdc++ parallel mode: Benefit from Multi-Core using
the STL", their measured speedups are almost the same (see page 18,
http://ls11-www.cs.uni-dortmund.de/people/gutweng/AD08/VO11_parallel_mode_overview.pdf);
they observer speedup over 20 with balanced quick sort using 32 threads.

Any idea why this happens or what do I wrong?

Daniel

Jonathan Wakely | 16 Apr 14:33 2015
Picon

Help needed debugging std::is_convertible problem (PR 65760)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65760

I don't understand why commenting out *any one* of the lines marked
(1), (2), (3), (4) causes this to compile:

#include <functional>

struct C {
    C() = default;

    C(std::function<C(int)>);  // (1)
    C(std::function<C(int, int)>); // (2)
    template <class T> C operator () (T&&); // (3)
    template <class T> C operator () (T&&, T&&); // (4)
};

int main() {
    C c = C();
}

My understanding is that the SFINAE constraint on the std::function
constructor needs to check std::is_convertible<C, C> which requires C
to be complete, but why does it only complain that C is incomplete
when all of (1) - (4) are present?

G++, Clang and EDG all agree on this behaviour, so I don't think it's
a compiler bug. The libc++ std::function works fine in this case, I
don't know what it does differently so that it works.

To fix it I am considering short-circuiting the constraint to not use
(Continue reading)

Federico Lenarduzzi | 14 Apr 17:17 2015

[PATCH] libstdc++: Fix exceptions being generated when compiling with -fno-exceptions

When the libstdc++ is compiled, the compiler sets the std::terminate_handler function with
__verbose_terminate_handler() or std::abort() depending on _GLIBCXX_HOSTED && _GLIBCXX_VERBOSE
being true or false.

However, even if we compile with -fno-exceptions, the compiler will use
__verbose_terminate_handler(), which uses exceptions. Therefore, the library is not fully exception-free.

This patch adds a check for __EXCEPTIONS to the #if _GLIBCXX_HOSTED && _GLIBCXX_VERBOSE condition. If
__EXCEPTIONS is defined, the compiler will use __verbose_terminate_handler() as a termination
function; otherwise it'll use std::abort() which doesn't have exceptions. It also makes
std::uncaught_exception() throw() return false if __EXCEPTIONS is not defined.

libstdc++-v3/
2015-04-14  Federico Lenarduzzi  <federico.lenarduzzi <at> tallertechnologies.com>

	* libsupc++/eh_catch.cc (std::uncaught_exception() throw()): Add an #else
	which returns false if __EXCEPTIONS is not defined.
	* libsupc++/eh_term_handler.cc: Add a check for __EXCEPTIONS to the #if.

---
 libstdc++-v3/libsupc++/eh_catch.cc        | 4 ++++
 libstdc++-v3/libsupc++/eh_term_handler.cc | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/libsupc++/eh_catch.cc b/libstdc++-v3/libsupc++/eh_catch.cc
index 43e875a..6b500f6 100644
--- a/libstdc++-v3/libsupc++/eh_catch.cc
+++ b/libstdc++-v3/libsupc++/eh_catch.cc
 <at>  <at>  -136,6 +136,10  <at>  <at>  __cxxabiv1::__cxa_end_catch ()
 bool
(Continue reading)

Rainer Orth | 14 Apr 14:59 2015
Picon
Picon

[v3] Ignore elfdump warnings in scripts/extract_symvers.pl

The libstdc++-v3 abi_check test is FAILing on Solaris 11 with gld.  It
turns out this happens because a elfdump warning (printed to stderr) is
mixed with regular elfdump output.  In the case at hand, elfdump warns

 .gnu.version_r: zero sh_entsize information, expected 0x1
 .gnu.version_d: zero sh_entsize information, expected 0x1

but obviously trying to parse warnings as regular output is doomed to
fail.  While it has been determined that those concrete warnings are
bogus and will be removed in the future, the general problem remains.
The following patch fixes this by just ignoring elfdump error output.

Bootstrapped without regressions on i386-pc-solaris2.1[01] and
sparc-sun-solaris2.1[01] (with as/ld, gas/gld) on both mainline and
gcc-5 branch.  Ok for mainline and gcc-5 branch?  I suppose the patch is
safe enough even at this point since it only affects a solaris specific
file.

	Rainer

2015-04-09  Rainer Orth  <ro <at> CeBiTec.Uni-Bielefeld.DE>

	* scripts/extract_symvers.pl: Ignore elfdump error output.


--

-- 
-----------------------------------------------------------------------------
(Continue reading)

Ville Voutilainen | 13 Apr 01:24 2015
Picon

[libstdc++ PATCH] Add support for std::uncaught_exceptions

The patch is a bit large since it does the baseline_symbols regeneration
and other new-version api-dance.
Hence attached gzipped.

Tested on Linux x86-64.

2015-04-13  Ville Voutilainen  <ville.voutilainen <at> gmail.com>
    Add support for std::uncaught_exceptions.
    * acinclude.m4: Bump libtool_VERSION.
    * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate.
    * config/abi/pre/gnu.ver: Export the new symbol.
    * configure: Bump libtool_VERSION.
    * libsupc++/eh_catch.cc(uncaught_exceptions): New.
    * libsupc++/exception(uncaught_exceptions): Ditto.
    * testsuite/18_support/uncaught_exceptions/uncaught_exceptions.cc: New.
    * testsuite/util/testsuite_abi.cc: Add 3.4.22 as the latest version.
Attachment (uncaught_exceptions.diff.gz): application/x-gzip, 25 KiB
Uros Bizjak | 12 Apr 08:41 2015
Picon

[PATCH, alpha]: Update libstdc++ baseline symbols

Hello!

2015-04-12  Uros Bizjak  <ubizjak <at> gmail.com>

    * config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update.

Tested on alpha-linux-gnu, committed to mainline SVN.

Uros.
Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt
===================================================================
--- config/abi/post/alpha-linux-gnu/baseline_symbols.txt	(revision 222007)
+++ config/abi/post/alpha-linux-gnu/baseline_symbols.txt	(working copy)
 <at>  <at>  -64,10 +64,13  <at>  <at> 
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE8overflowEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9pbackfailEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9underflowEv <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED0Ev <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED1Ev <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEaSEOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4fileEv <at>  <at> GLIBCXX_3.4.2
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4syncEv <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE5uflowEv <at>  <at> GLIBCXX_3.4.10
 <at>  <at>  -78,10 +81,13  <at>  <at> 
(Continue reading)

Jonathan Wakely | 10 Apr 22:52 2015
Picon

[patch] Update libstdc++ evolution docs

I'm sure this still isn't complete, but at least it now contains
information for releases since 4.5, and documents any deprecations.

Committed to trunk.
Attachment (patch.txt): text/x-patch, 4535 bytes
Andreas Schwab | 10 Apr 22:08 2015

[PATCH] ia64: update libstdc++ baseline symbols

Tested on ia64-suse-linux, installed as obvious.

Andreas.

	* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.

diff --git a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
index 640d9ec..52392bc 100644
--- a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
 <at>  <at>  -64,10 +64,13  <at>  <at>  FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE7seekposESt4fposI11__
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE8overflowEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9pbackfailEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9underflowEv <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED0Ev <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED1Ev <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEaSEOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4fileEv <at>  <at> GLIBCXX_3.4.2
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4syncEv <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE5uflowEv <at>  <at> GLIBCXX_3.4.10
 <at>  <at>  -78,10 +81,13  <at>  <at>  FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE7seekposESt4fposI11__
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE8overflowEj <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9pbackfailEj <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9underflowEv <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC1EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC1EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
(Continue reading)


Gmane