Matthias Klose | 21 Jan 20:19 2015

(missing?) symbols in 32bit libstdc++ builds?

I see some symbols "missing" from 32bit libstdc++ builds. In the past these were
not architecture specific.  Is this an issue, or are these symbols expected to
be defined on 64bit architectures only?

thanks, Matthias

 <at>  <at>  -4758,8 +4758,8  <at>  <at> 
  _ZTSPKj <at> CXXABI_1.3 4.1.1
  _ZTSPKl <at> CXXABI_1.3 4.1.1
  _ZTSPKm <at> CXXABI_1.3 4.1.1
- _ZTSPKn <at> CXXABI_1.3.9 5
- _ZTSPKo <at> CXXABI_1.3.9 5
+#MISSING: 5-20150121-1# _ZTSPKn <at> CXXABI_1.3.9 5
+#MISSING: 5-20150121-1# _ZTSPKo <at> CXXABI_1.3.9 5
  _ZTSPKs <at> CXXABI_1.3 4.1.1
  _ZTSPKt <at> CXXABI_1.3 4.1.1
  _ZTSPKv <at> CXXABI_1.3 4.1.1
 <at>  <at>  -4778,8 +4778,8  <at>  <at> 
  _ZTSPj <at> CXXABI_1.3 4.1.1
  _ZTSPl <at> CXXABI_1.3 4.1.1
  _ZTSPm <at> CXXABI_1.3 4.1.1
- _ZTSPn <at> CXXABI_1.3.9 5
- _ZTSPo <at> CXXABI_1.3.9 5
+#MISSING: 5-20150121-1# _ZTSPn <at> CXXABI_1.3.9 5
+#MISSING: 5-20150121-1# _ZTSPo <at> CXXABI_1.3.9 5
  _ZTSPs <at> CXXABI_1.3 4.1.1
  _ZTSPt <at> CXXABI_1.3 4.1.1
  _ZTSPv <at> CXXABI_1.3 4.1.1
 <at>  <at>  -4916,8 +4916,8  <at>  <at> 
  _ZTSj <at> CXXABI_1.3 4.1.1
(Continue reading)

François Dumont | 20 Jan 00:10 2015

Reorganize and clean debug headers


     While working on new debug checks I came up with reorganizing 
existing ones to limit as much as possible useless includes.

     Tested under linux x86_64.

     From the latest mails I saw on this mailing list I guess I must 
wait, right ?

2015-01-20  François Dumont  <fdumont <at>>

     * include/debug/debug.h ([_GLIBCXX_DEBUG_ASSERT,
     * include/debug/assertions.h:, new.
     * include/debug/functions.h (__foreign_iterator): Move definition...
     * include/debug/functions.tcc:, new.
     * include/ Add new above debug files.
     * include/ Regenerate.
     * include/debug/formatter.h: Include typeinfo only if rtti enabled.
     [_GLIBCXX_TYPEID]: New, use it throughout the file.
     * include/debug/safe_iterator.h: Replace debug.h include with
     (__check_dereferenceable, __valid_range): Move here overload for
     (struct __is_safe_random_iterator): Move here partial specialization
     for _Safe_iterator.
     (__check_singular_aux): Move...
     * include/debug/safe_base.h (__check_singular_aux): ... here.
     * include/debug/safe_local_iterator.h (__check_dereferenceable)
(Continue reading)

Jonathan Wakely | 19 Jan 17:02 2015

[patch] libstdc++/64658 define std::atomic_init()

We declare atomic_init() but then never define it, I assume that's
just an accident.

Although the standard says this function is non-atomic, the simplest
fix at this stage is just to do an atomic store (when we get to stage
1 again I'd like to make the function a friend of std::__atomic_base<>
so it can set the private member variable directly as a simple
non-atomic assignment).

Tested x86_64-linux, *not* committed to trunk.
Attachment (patch.txt): text/x-patch, 2172 bytes
Jonathan Wakely | 19 Jan 16:35 2015

[patch] libstdc++/64650 add bad_optional_access default constructor

The Library Fundamentals TS says
std::experimental::bad_optional_access should have a default
constructor, but we only support construction from strings.

This removes the unused and non-standard std::string constructor and
adds the required default constructor.

Tested x86_64-linux, *not* committed.
Attachment (patch.txt): text/x-patch, 1616 bytes
Jonathan Wakely | 18 Jan 17:31 2015

[patch] libstdc++/64646 fix 4-iterator overload of std::is_permutation

Fix a past-the-end dereference in the new C++14 version of
is_permutation. This only affects C++14 mode, but fixes a new function
that exists entirely because it's meant to be safer than the C++98
version ... but it isn't safer if it goes past-the-end!

Tested x86_64-linux, committed to 4.9 and trunk.
Attachment (patch.txt): text/x-patch, 2354 bytes
Tim Shen | 18 Jan 08:09 2015

[Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname

Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.


Tim Shen
commit e433cdbe4a1b8660fcd452c1a5e08972c495d08f
Author: timshen <timshen <at>>
Date:   Sat Jan 17 19:34:14 2015 -0800

    	PR libstdc++/64649
    	* include/bits/regex.tcc (regex_traits<>::lookup_collatename,
    	regex_traits<>::lookup_classname): Conform forward iterator constrain
    	for lookup_collatename lookup_classname.
    	* testsuite/28_regex/traits/char/ New testcases.
    	* testsuite/28_regex/traits/char/ New testcase.

diff --git a/libstdc++-v3/include/bits/regex.tcc b/libstdc++-v3/include/bits/regex.tcc
index 4ea8180..3f16e66 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
 <at>  <at>  -267,53 +267,17  <at>  <at>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
-	  ""
(Continue reading)

Jonathan Wakely | 17 Jan 04:25 2015

[patch] Update C++11 status in libstdc++ docs

Update the C++11 library status table and regenerate HTML.

Committed to trunk.

Attachment (patch.txt): text/x-patch, 5106 bytes
Jakub Galgonek | 16 Jan 08:05 2015

std::vector<T> does not use the move constructor of T to change its capacity


I have made some experiments with move constructors in C++ 11 (in g++
4.8.3 and g++ 4.9.2) and I have observed that std::vector<T> uses the
copy constructor (instead of the move constructor) of T to change the
capacity of a vector instance.

For example, the following code:

#include <iostream>
#include <vector>

class Test {
        Test() { }
        Test(const Test &ins) { std::cout << "copy constructor" << std::endl; }
        Test(const Test &&ins) { std::cout << "move constructor" << std::endl; }

int main() {
        Test t1, t2, t3;
        std::vector<Test> vector;

        std::cout << "-----" << std::endl;
        std::cout << "-----" << std::endl;
        std::cout << "-----" << std::endl;
        std::cout << "-----" << std::endl;
(Continue reading)

François Dumont | 12 Jan 22:23 2015

Debug checks and constexpr


     With recent additions of _GLIBCXX14_CONSTEXPR on a number of algos 
came regressions in debug mode. This is not the first time we have this 
kind of issue and surely won't be the last.

     So I can only think about one way to make it work. We should be 
able to tell the compiler to ignore debug checks when called in a const 
expression context. Is there already a way to do so ? If not is there 
any plan to do something similar ? Or anyone can think of a different 
way to deal with this problem ?


Jonathan Wakely | 9 Jan 15:40 2015

[patch] libstdc++/60966 fix packaged_task also

The race conditions fixed in PR 60966 can also happen when using
std::packaged_task (on the release branches only, the fix applied to
the trunk covers all cases).

The problem is that the mutex protecting the result in the shared
state is unlocked before the _M_cond.notify_all() call. This leaves a
small window where threads waiting on the future can see the result
(and so return from a waiting function) before the notify_all(). If
the waiting thread destroys the future *and* the
packaged_task as soon as the waiting function returns, then _M_cond
will be destroyed before the notify_all() call on it, resulting in
undefined behaviour (typically this means blocking forever in the
pthread_cond_broadcast() call).

This patch uses the same approach as done for std::promise on the
release branches: increasing the ref-count on the shared state until
the function setting the result has completed. This ensures that the
shared state (and its condition_variable member) will not be destroyed 
until after the _M_cond.notify_all() call.

Thanks to Barry Revzin for finding the problem and Michael Karcher for
debugging it.

The original fixes for 60966 solved the problem for std::promise, this
solves it for std::packaged_task. The only other types of asynchronous
result providers are those created by std::async, but for those types
the waiting functions already block in _M_complete_async() so cannot
return before the notify_all() call happens.

Tested x86_64-linux, committed to the 4.9 and 4.8 branches.
(Continue reading)

Jonathan Wakely | 8 Jan 16:04 2015

Re: [Patch]New feature to all kind of stl container.vector::data_move()returns vector::data() that can be moved,just as unique_ptr::release() to unique_ptr::get()

On 8 January 2015 at 13:54, 魅影圣域 wrote:
> You are right.I'm not sure of the interface.I can now only be sure of the need.
> RAII is important too.
> My opinion's good part is:make it possible for resouce moving from vector to
SomeHoldingArrayDataClass,not only now just vector to another vector.I suggest data_move() only
because if data_move() is at hand,stl users can easily make that possible.
> Your example can't handle resouce moving:
>> extern "C" void some_function(const int*, size_t);
>> std::vector<int> get_values(size_t n);
>> ...
>> some_function(get_values(5).data(), 5);
> what if some_function save get_values(5).data() to somewhere out of the scope?

I'm not sure what your point is, but some_function doesn't do that.