François Dumont | 17 Oct 22:46 2014

[Bug libstdc++/61107] stl_algo.h: std::__inplace_stable_partition() doesn't process the whole data range


     As proposed in the bug report I just removed the 
__inplace_stable_partition as __stable_partition_adaptive is able to 
handle a 0 buffer size.

     To test this bug I introduced overloads of new/delete operators in 
the testsuite utils. The existing set_memory_limits has no impact on new 
operator. I wonder if some test using it really have the expected behavior.

     I also tests other algos that try to use a buffer and didn't found 
any issue. Those algos however can't be simplified like stable_partition.

2014-10-16  François Dumont <fdumont <at>>

     PR libstdc++/61107
     * include/bits/stl_algo.h (__inplace_stable_partition): Delete.
     (__stable_partition): Adapt.
     * testsuite/util/testsuite_new_operators.h: New.
     * testsuite/25_algorithms/stable_sort/ Test algo in simulated
     constraint memory context.
     * testsuite/25_algorithms/inplace_merge/ Likewise.
     * testsuite/25_algorithms/stable_partition/ Likewise.

Tested under Linux x86_64.

Ok to commit ?

(Continue reading)

Jonathan Wakely | 17 Oct 14:34 2014

[wwwdocs] Add recent C++ changes to gcc-5/changes.html

Committed to CVS.
Attachment (patch.txt): text/x-patch, 3947 bytes
Paolo Carlini | 15 Oct 23:10 2014

[v3] Update a testcase vs c++/53000


contributed by Daniel. Thanks!


2014-10-15  Daniel Krugler  <daniel.kruegler <at>>

	* testsuite/20_util/common_type/requirements/
	Enable tests predicated on PR c++/53000.

Index: testsuite/20_util/common_type/requirements/
--- testsuite/20_util/common_type/requirements/	(revision 216284)
+++ testsuite/20_util/common_type/requirements/	(working copy)
 <at>  <at>  -21,9 +21,6  <at>  <at> 
 #include <type_traits>
 #include <initializer_list>

-//TODO: Uncomment this once gcc bug 53000 has been resolved:
-//#define HAS_53000_FIXED
 // Helper types:
 struct has_type_impl
(Continue reading)

Jonathan Wakely | 15 Oct 15:20 2014

[patch] Add missing 'const' to std::complex primary template

Some more constexpr members that need to be 'const' in C++14.

Tested x86_64-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 2232 bytes
John Schmerge | 15 Oct 05:15 2014

Missing codecvt specializations and <codecvt> header and a request for some guidance

Hi guys,

I'm looking for some guidance. As part of implementing a version of
the std::filesystem proposal, I've needed to flesh out pieces of the
missing codecvt classes for the standard library.

Right now, I have a poorly organized version of the codecvt
specializations for char16_t and char32_t and a version of
codecvt_utf8 up on github (and should have the
codecvt_utf16/utf8_utf16 classes in a workable state in a few days).

I'd like to contribute this code to libstdc++ when its complete, and
I'm at a bit of a loss as to what the best way to go about that might
be. Any thoughts on how to do so would be appreciated.

You can find the code I'm speaking of here:


François Dumont | 14 Oct 23:51 2014

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?


     Here is a proposal to fix the issue with iterators which do not 
expose lvalue references when dereferenced. I simply chose to detect 
such an issue in c++11 mode thanks to the is_lvalue_reference meta function.

2014-10-15  François Dumont  <fdumont <at>>

     PR libstdc++/63500
     * include/bits/cpp_type_traits.h (__true_type): Add __value constant.
     (__false_type): Likewise.
     * include/debug/functions.h (__foreign_iterator_aux2): Do not check for
     foreign iterators if input iterators returns rvalue reference.
     * testsuite/23_containers/vector/ New.

Tested under Linux x86_64.


Attachment (debug.patch): text/x-patch, 3237 bytes
Jonathan Wakely | 10 Oct 18:15 2014

Regenerated libstdc++-v3/testsuite/

I've regenerated this file and committed it so I don't get harmless
whitespace changes every time I run autoreconf.

Ville Voutilainen | 8 Oct 22:28 2014

[PATCH] PR libstdc++/60132, implement the remaining C++11 is_trivially_* traits

Tested on Linux-X64.

Massive thanks to Jason for doing the heavy lifting on the front-end side.

2014-10-08  Ville Voutilainen  <ville.voutilainen <at>>

    PR libstdc++/60132
    * include/std/type_traits (is_trivially_copyable,
is_trivially_constructible, is_trivially_default_constructible,
is_trivially_copy_constructible, is_trivially_move_constructible,
is_trivially_assignable, is_trivially_copy_assignable,
is_trivially_move_assignable): New.
    * testsuite/20_util/is_trivially_assignable/requirements/ New.
    * testsuite/20_util/is_trivially_assignable/requirements/
    * testsuite/20_util/is_trivially_assignable/ New.
    * testsuite/20_util/is_trivially_constructible/requirements/
    * testsuite/20_util/is_trivially_constructible/requirements/
    * testsuite/20_util/is_trivially_constructible/ New.
    * testsuite/20_util/is_trivially_copyable/requirements/ New.
    * testsuite/20_util/is_trivially_copyable/requirements/
    * testsuite/20_util/is_trivially_copyable/ New.
    * testsuite/20_util/is_trivially_copy_assignable/requirements/
    * testsuite/20_util/is_trivially_copy_assignable/requirements/
    * testsuite/20_util/is_trivially_copy_assignable/ New.
(Continue reading)

Jonathan Wakely | 8 Oct 10:43 2014

Re: sort_heap complexity guarantee

On 06/10/14 23:00 +0200, François Dumont wrote:
>Good point, with n calls to pop_heap it means that limit must be 
>2*log(1) + 2*log(2) +... + 2*log(n) which is 2*log(n!) and  which is 
>also necessarily < 2*n*log(n). I guess Standard comittee has forgotten 
>the factor 2 in the limit so this is what I am using as limit in the 
>final test, unless someone prefer the stricter 2*log(n!) ?
>Ok to commit those new tests ?

Yes please - thanks.

Ivo Doko | 8 Oct 01:18 2014

Possible improvement to std::list::sort


I would like to submit for your consideration an algorithm which, in my 
tests, (mostly) outperforms std::list::sort as currently implemented in 

For convenience, besides the attachment, the source code is also 
available here:

I hope the comments in the code adequately explain how the algorithm 
works. Basically, it is in-place mergesort with an additional pre-merge 
pass which builds sorted regions from pre-existing ascending and 
descending runs. Of course, the sorting is stable.

For lists which are already sorted, the algorithm trivially runs in 
O(n). The same is true for lists which are sorted in reverse and have no 
duplicate values. From my testing, the algorithm performs as well as 
std::list::sort when compiled without optimisation, but with 
optimisation (even with just "-O"), it runs about 30-40% faster than 
std::list::sort on randomly generated lists. (This may imply that the 
code can be additionally optimised, or maybe these are simply 
optimisations beyond a programmer's reach.)

The bad thing, however, is that the worst-case for the algorithm is 
trivially constructible - it is a list of the form
{largest, smallest, 2nd largest, 2nd smallest, ...}.
E.g., for an empty std::list<size_t> lst and length size_t n, this can 
be constructed by the following:

for(size_t i = 0; i < n; ++i)
(Continue reading)

François Dumont | 5 Oct 22:00 2014

sort_heap complexity guarantee


     I took a look at PR 61217 regarding pop_heap complexity guarantee. 
Looks like we have no test to check complexity of our algos so I start 
writing some starting with the heap operations. I found no issue with 
make_heap, push_heap and pop_heap despite what the bug report is saying 
however the attached testcase for sort_heap is failing.

     Standard is saying std::sort_heap shall use less than N * log(N) 
comparisons but with my test using 1000 random values the test is showing:

8687 comparisons on 6907.76 max allowed

     Is this a known issue of sort_heap ? Do you confirm that the test 
is valid ?

     Note that counter_type needs a patch to make the test ok, 
less_compare_count must be updated when operator< is invoked.



Attachment ( text/x-c++src, 1663 bytes