Siva Chandra | 29 Sep 15:02 2014

Refactor python/

The attached patch refactors python/ so that there are no
individual function calls to load pretty printers and xmethods. This
was suggested by Tom here: He indicates
that it is better to put as little as possible in the hook file. The
attached patch removes all code which explicitly loads the hooks from

2014-09-29  Siva Chandra Reddy  <sivachandra <at>>

        * python/ Only import libstdcxx.v6.
        * python/libstdcxx/v6/ Load printers and xmethods.
diff --git a/libstdc++-v3/python/ b/libstdc++-v3/python/
index aeb1cdb..30cf538 100644
--- a/libstdc++-v3/python/
+++ b/libstdc++-v3/python/
 <at>  <at>  -55,18 +55,4  <at>  <at>  if gdb.current_objfile () is not None:
     if not dir_ in sys.path:
         sys.path.insert(0, dir_)

-# Load the pretty-printers.
-from libstdcxx.v6.printers import register_libstdcxx_printers
-register_libstdcxx_printers (gdb.current_objfile ())
-# Load the xmethods if GDB supports them.
-def gdb_has_xmethods():
-    try:
-        import gdb.xmethod
(Continue reading)

Jonathan Wakely | 25 Sep 00:18 2014

[patch] libstdc++/56193 re-add basic_ios::operator bool()

This changes operator void*() to operator bool(), and ensures we
export both from the library.

I have a new test for this, but will commit that tomorrow.

Tested x86_64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 2212 bytes
Jonathan Wakely | 24 Sep 23:22 2014

Bikeshed discussion on name of library file for Filesystem TS

I'm going to commit <experimental/filesystem> soon, and as previously
explained, all the new code is in a separate archive, not in

I think I called that archive libstdc++fs.a but it might be a good
idea to discuss better names.

* Should the name have libstdc++ or GNU in it somewhere, to
distinguish our library from another implementation's? Or would it be
better if different implementations used the same name, so users'
makefiles are simpler?

* Should the archive name indicate the TS contents are "experimental"
(as the namespace and include path already do)?

Some options include:


Or any of the above with "fs" or "filesystem" instead of "file".

Or there's the accurate-but-not-very-exciting name, libts18822.a,
since the document is ISO/IEC TS 18822.

I'm hoping there's a really good name that I just haven't thought of!
(Continue reading)

Jonathan Wakely | 23 Sep 13:19 2014

stdio_filebuf is instantiated in the library but not exported

While working on iostream move semantics I noticed that we define an
explicit instantiation of __gnu_ext::stdio_filebuf<char> and
__gnu_ext::stdio_filebuf<wchar_t> in src/c++98/ (which I
moved to src/c++11/ yesterday).

But we don't declare those explicit instantiations in any header, and
don't export the symbols, so the instantiations are only for the
library's own use, is that indented?

DJ Delorie | 22 Sep 18:59 2014

ping [Re: __intN patch 3/5: main __int128 -> __intN conversion.]

On Sep 5th I posted:

Can someone please review the c++/libstdc++ parts?

Jonathan Wakely | 22 Sep 17:25 2014

[patch] Update C++11 library status docs

This documents some more C++11 features as incomplete and notes that
iostreams are movable now.

Committed to trunk.
Attachment (patch.txt): text/x-patch, 4470 bytes
Fran├žois Dumont | 21 Sep 23:29 2014

Profile mode maintenance patch


     Here is the promise major patch for the profile mode. Here are the 
most important modifications.

     Now instance of profiling structs are kept as pointers in the 
containers themselves. It has an impact on the container ABI but it 
greatly enhance performances as we do not need to move through a search 
in an unordered container which also imply a lock during this research. 
I have even been able to remove those unordered containers eventually 
just keeping a counter of allocated bytes to know if we should stop 
creating new profiling structs.

     I get rid of the re-entrancy mechanism. The only reason for it was 
a potential hook in the memory allocator potentially creating new 
profiling structs and so long forever. I prefer to put it just where it 
is necessary that is to say when we first allocate memory for profiling 
which is then we create the back-trace.

     I wonder if we shouldn't emit a #error when trying to activate 
profiling mode without backtrace feature cause in this case we simply 
won't collect anything.

     I finalize ordered to unordered profiling by adding the missing 
__iterator_tracker on the ordered containers (map, multimap, set, multiset).

     I clean all useless stuff like __stack_info_base class.

     I fixed many memory leak and added a cleanup at exit of the 
(Continue reading)

Jonathan Wakely | 19 Sep 14:35 2014

Do the <at> require <at> and <at> diff <at> comments in testsuite/27_io files do anything?

We have comments like these in a number of file I/O tests

e.g. testsuite/27_io/ios_base/sync_with_stdio/ has:

//  <at> require <at>  %-*.tst
//  <at> diff <at>  %-*.tst %-*.txt

They suggest that the .txt file written by the test will be diffed
with a .tst reference file, but I don't think that diffing actually

Is this a remnant of an old testsuite?

Does it matter if we're not checking the file contents match?

Jonathan Wakely | 17 Sep 16:36 2014

Why doesn't <ctgmath> include <ccomplex>?

Our <ctgmath> only includes <cmath>, not <ccomplex> as required by
26.8 [c.math] paragraph 1.

Is that intentional?

Ed Smith-Rowland | 14 Sep 03:58 2014

[C++14] Add is_final type trait.

We've had __has_final built-in for a good while.
the std library component is_final was added to C++14 - which is now good.
I noticed while looking at the latest SD-6 draft.

So here is a simple patch that builds and passes clean on x86_64-linux.


2014-09-14  Edward Smith-Rowland  <3dw4rd <at>>

	* include/std/type_traits: Add is_final<> type trait for C++14.
	* testsuite/util/testsuite_tr1.h: Add 
	* testsuite/20_util/is_final/requirements/ New.
	* testsuite/20_util/is_final/requirements/ New.
	* testsuite/20_util/is_final/ New.
	* testsuite/20_util/declval/requirements/ Adjust.
	* testsuite/20_util/make_signed/requirements/ Adjust.
	* testsuite/20_util/make_unsigned/requirements/ Adjust.

Index: include/std/type_traits
--- include/std/type_traits	(revision 215247)
+++ include/std/type_traits	(working copy)
 <at>  <at>  -634,6 +634,15  <at>  <at> 
     : public integral_constant<bool, __is_polymorphic(_Tp)>
(Continue reading)

Jonathan Wakely | 9 Sep 19:31 2014

[patch] Make std::deque meet C++11 allocator requirements

This was a tricky one, because std::deque always has a map of nodes
allocated, so needs to re-allocate in its move constructor. That makes
move assignment complicated, as the rvalue object must be left in a
valid state owning memory that can be freed by its (possibly
moved-from) allocator.

The _M_replace_map(_Args&&...) function constructs a new deque from
its arguments, rips the guts out of that new deque and then destroys
it. When the argument to the new deque is an rvalue deque the move
constructor takes care of leaving the rvalue in a valid state with
memory that can be freed by its allocator.

The common case with std::allocator allows move-assignment to be
noexcept, because it only involves swapping a few pointers and calling

As an extension we support move assignment of std::deque even if the
element types are not assignable, as long as the allocator type
propagates (as we do for std::vector, see PR52591).

Tested x86_64-linux, normal, debug and profile modes.

Committed to trunk.
Attachment (patch.txt): text/x-patch, 51 KiB