Aurelio Remonda | 8 Oct 15:35 2015

[PATCH] Random shuffle moveable: container size

This patch reduces the size of the array A (the array that contains
the values being shuffled) so the test can pass while running the
stdlibc++ testsuite.
It also make some minor changes such as:
*Deleting a useless call to fill_ascending function on test02.
*Changing N from const int to const unsigned int.
I have a company-wide copyright assignment, but I don't have commit access.

 ChangeLog   |  6 ++++++ | 13 ++++++-------
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 91d2957..2c4e127 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
 <at>  <at>  -1,3 +1,9  <at>  <at> 
+2015-10-08  Aurelio Remonda  <aurelio.remonda <at>>
+	* testsuite/25_algorithms/random_shuffle/ Change variable
+	N from const int N = 200000 to const unsigned int N = 10000.
+	Delete useless fill_ascending function call.
 2015-09-07  Jonathan Wakely  <jwakely <at>>

 	* include/bits/shared_ptr_base.h (__shared_ptr::operator->): Change
diff --git a/libstdc++-v3/testsuite/25_algorithms/random_shuffle/ b/libstdc++-v3/testsuite/25_algorithms/random_shuffle/
index e854c38..dabe9e3 100644
--- a/libstdc++-v3/testsuite/25_algorithms/random_shuffle/
(Continue reading)

Jonathan Wakely | 7 Oct 23:02 2015

[patch] Backport C++ Filesystem TS fixes to gcc-5-branch

Since I backported the Filesystem lib to the gcc-5-branch in
mid-August there have been some bugfixes on trunk, and dual ABI
support in libstdc++fs.a, so I'm backporting those changes to the
branch too.

This also removes some empty TODO files I accidentally added on the
branch, which were only meant to be in my local tree not checked in!

Tested powerpc64le-linux, committed to gcc-5-branch.

Attachment (patch.txt): text/x-patch, 50 KiB
Jonathan Wakely | 3 Oct 14:09 2015

[patch] Two tiny libstdc++ cleanups

This fixes some misleading comments (getenv isn't used in those files)
and removes pretty-printer support for experimental::any objects that
use allocators, as the allocator feature was removed from the TS and
dropped in r218709 before it was included in a GCC release.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 2381 bytes
Jonathan Wakely | 3 Oct 01:43 2015

[patch] Fix testsuite failures with --disable-wchar_t

This fixes some FAILs seen with --disable-wchar_t, and for targets
where that's the default.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 5587 bytes
Jonathan Wakely | 3 Oct 01:22 2015

[patch] Enable dual ABI for Filesystem TS

Currently the Filesystem TS library, libstdc++fs.a, only has symbols
for one ABI, whichever is configured as the default when GCC is built.

This adds dual ABI support, by building the relevant files twice, once
with each ABI (as we do already for and libstdc++.a).

Tested powerpc64le-linux (both ABIs), committed to trunk.

Attachment (patch.txt): text/x-patch, 7905 bytes
Jonathan Wakely | 29 Sep 18:31 2015

The note about improving std::to_string() for SSO strings

Hi Paolo,

I've been looking at this note in <ext/string_conversions.h> now that
we have a new std::string:

      // XXX Eventually the result will be constructed in place in
      // the C++0x string, likely with the help of internal hooks.
      _CharT* __s = static_cast<_CharT*>(__builtin_alloca(sizeof(_CharT)
                                                          * __n));

I see a couple of ways to do that.

1) Create a string that has the maximum size for an SSO string:

    _String __str;

then try to print the number into it. If it fits, return it, otherwise
grow the string by re-allocating with resize() and print into it again,
then return it.

2) Use alloca() to create a buffer that has room for a string and the
big-enough buffer of sizeof(_CharT) + __n bytes, overlapping like so:

    | _M_pointer       |
    | _M_string_length |
    | _M_local_buf     | __s              |
(Continue reading)

Jonathan Wakely | 29 Sep 17:15 2015

[patch] Leave errno unchanged by successful std::stoi etc

We set errno=0 in __gnu_cxx::__stoa in order to reliably detect when
it gets set to ERANGE. This restores the previous value when the
conversion is successful.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 2430 bytes
Christopher Jefferson | 27 Sep 00:15 2015

Re: [Testsuite] random shuffle moveable issue

On 25 September 2015 at 22:20, Aurelio Remonda
<aurelio.remonda <at>> wrote:
> El sep 25, 2015 2:12 PM, "Christopher Jefferson" <chris <at>>
> escribió:
>> I assume this means that the board is failing to handle a global
>> variable of int[200000] correctly?
>> How small do you have to make the array to make the test pass? The
>> algorithm isn't testing anything specific with an array that big,
>> certainly I imagine 10,000 would be more than enough to get the same
>> quality of test coverage (probably even 100 to be honest, but bigger
>> doesn't hurt).
> Christopher thank you for your reply!
> You can easily make its size of around 30000 so if 10000 is more than enough
> it can
> be done!
> I have a question about the code if you don't mind. Why in the test02 the
> fill_ascending()
> call is needed? If i understood it correctly the random_shuffle is made on
> rv[ ] and then
> it is compared with result [ ]. Am i correct? :)

(Continue reading)

Aurelio Remonda | 25 Sep 15:23 2015

[Testsuite] random shuffle moveable issue

Hello, i was running gcc tests on RTEMS, with rtems-testing and qemu
simulating a realview pbx a9 board.
On the libstdc++ summary i got this failure (among others).
FAIL: 25_algorithms/random_shuffle/ execution test.

When debugged it turns out that all three VERIFY pass (cout of the
same line gave 1, is an equal) but i didn't get the exit code 0 at the
end of the simulation. Apparently, this is making DejaGNU think
something's wrong. If i reduce the size of A (the array that contains
the values being shuffled) the test runs correctly.

If this can be modified i will be happy to send the patch.
Thank you.

Jonathan Wakely | 23 Sep 13:39 2015

[v3 patch] Fix Filesystem TS directory iterators

directory_iterator and recursive_directory_iterator fail to meet this
requirement in

  The directory_iterator default constructor shall create an iterator
  equal to the end iterator value, and this shall be the only valid
  iterator for the end condition.

The current code creates the end iterator when an error occurs during
construction and an error_code parameter was used (so an exception
is not thrown, but construction finishes normally and sets the

This fixes it by creating a distinct error state that is not the end
iterator state:

  // An error occurred, we need a non-empty shared_ptr so that *this will
  // not compare equal to the end iterator.

This way the shared_ptr owns a null pointer, so (bool)_M_dir is false
(and we don't allow incrementing or dereferencing) but it can be
distinguished from an empty shared_ptr by comparing them using

(The order of the owner_before checks is chosen so that the common
case of testing iter != directory_iterator() should short-circuit and
only check the first condition).

There were a few other problems with directory iterators, including
the fact that the get_file_type function never worked because autoconf
(Continue reading)

Jonathan Wakely | 18 Sep 14:59 2015

[PATCH] Use stdint-wrap.h on *-*-netbsd[56]*

This patch adjust config.gcc so that it installs <stdint.h> for NetBSD
5.x and 6.x, which is necessary for the C++ library because the host
<stdint.h> has:

#if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS)
#include <machine/int_limits.h>

#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)
#include <machine/int_const.h>

This means that contrary to the C++11 standard the stdint macros are
only defined when __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS are

I first noted the problem earlier this year and opened 

I rediscovered the problem when I broke netbsd bootstrap by including
<ext/random> during bootstrap with

That header uses UINT32_C, which is not defined without this patch.

NetBSD 7.x should be OK, because it knows about C++11 (see the link in
the PR for details).

Tested x86_64-unknown-netbsd5.1, OK for trunk?

(Continue reading)