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
Stefan Schweter | 7 Sep 16:15 2014

std::regex: inserting std::wregex to std::vector loses some std::wregex values


using GCC 4.9.1 it can reproduce a strange behavior with inserting
std::wregex values to a std::vector.

I'm using a loop which creates some std::wregex with imbuing and assigning.

After compiling and executing the program code, a core dump is returned.
Having a deeper look with gdb into the std::vector I can see, that only
the half of the std::wregex values have been properly inserted -> see
the _M_original_str variable.

Here is my code to reproduce the error:

#include <regex>
#include <vector>

int main()
  std::setlocale(LC_ALL, "");

  std::wstring current_token(L"II.");

  std::vector<std::wregex> regex_vector;

  for (int i = 0; i < 4; ++i)
    std::regex_constants::syntax_option_type flag;
    flag = std::regex_constants::icase;

(Continue reading)

Diego Novillo | 5 Sep 15:08 2014

GNU Tools Cauldron 2014 - Videos for presentations

All the videos for Cauldron 2014 are now available at the
conference page:

Thanks to Simon Cook for processing the videos and setting them

If you notice anything missing or mis-labeled, please let me

Thanks. Diego.

Thomas Schwinge | 5 Sep 13:05 2014

libstdc++ testsuite "misbehaving"


Updating my GCC trunk working tree from r212389 (2014-07-09) to r214918
(2014-09-04), I notice that (only) in libstdc++ testing, and only for the
second multilib of »RUNTESTFLAGS='--target_board=unix\{,-m32\}'« (so, the
32-bit x86 one), a lot of PASSes "disappear" (compile tests only?).  Has
anyone seen this before, and/or an explanation for this?

Here's a diff of the sum file that shows how the »unix« variant behaves
as expected, but for the »unix/-m32« one a lot of PASSes disappear, and
in the latter's summary the »# of expected passes« is basically cut into

     Native configuration is x86_64-unknown-linux-gnu

                    === libstdc++ tests ===

     Schedule of variations:

     Running target unix
                    === libstdc++ Summary for unix ===

    -# of expected passes           9368
    -# of unexpected failures       1
    +# of expected passes           9552
     # of expected failures         69
(Continue reading)

Jonathan Wakely | 2 Sep 11:59 2014

PR libstdc++/49813 revisited: constexpr on <cmath> functions (and builtins)

Rev 176847 (aka e9fea850 in Git) added _GLIBCXX_CONSTEXPR to the
declarations in include/c_global/cmath but that is expressly forbidden
by  [constexpr.functions] (as modified by LWG 2013

In the PR trail Paolo argues that we don't want different behaviour
for -std=c++11 and -std=gnu++11, so I believe in that case we must
*never* declare those functions as constexpr.

However, Marc has previously suggested that we can, and should, add
constexpr to more functions in -std=gnu++11 mode, since that is
already not strictly conforming. That is consistent with Jason's view
in i.e.
"G++ treating built-ins as constexpr is an extension, which should be
disabled in strict conformance mode."

However, rather than doing that as described in Jason changed
the FE so all builtins (including std functions that get handled by
builtins) are treated as constexpr, because the original proposed
resolution of LWG 2013 was going to allow us to add constexpr, but
that was reversed for the final resolution.

I believe we should re-open the bug in light of the actual resolution
of LWG 2013 (adding constexpr is forbidden).

The FE should not treat builtins as constexpr in strict-conformance

We should either remove _GLIBCXX_CONSTEXPR from <cmath> entirely or
(Continue reading)

Jonathan Wakely | 29 Aug 16:16 2014

Typedef for iterators denoting positions to insert/erase

In the new std::string implementation I'm using the following typedef:

#if __cplusplus < 201103L
      typedef iterator __pos_iterator;
      typedef const_iterator __pos_iterator;

This can then be used to avoid littering the rest of the file with preprocessor
conditionals like:

#if __cplusplus >= 201103L
      erase(const_iterator __first, const_iterator __last) noexcept
      erase(iterator __first, iterator __last)

Is this worth doing in the other containers too?

I'm undecided whether it's clearer to read the preprocessor condition
or a declaration with the non-standard __pos_iterator type, but I
think I'd prefer to use the new type. Any other opinions?

Jonathan Wakely | 28 Aug 17:46 2014

[patch] Adjust comments in testsuite/ext/random/

The tests for the non-standard distributions have bogus standard
references. [rand.concept.dist] comes from an old C++0x draft, and the
[rand.dist.ext.*] labels are entirely fictional because obviously
non-standard extensions are not in the standard.

Tested x86_64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 30 KiB
Jonathan Wakely | 27 Aug 19:50 2014

[patch] Only configure libstdc++-v3/python dir for hosted builds

Currently a freestanding build installs the Python GDB hooks as
${libdir}/libstdc* (with a literal * character in the filename)
because there is no library file and the wildcard doesn't
get expanded (see the install-data-local target in the
libstdc++-v3/python/ file).

I don't see any reason to install any Python files for a freestanding
build, the pretty printers and type printers are only useful for types
defined in the hosted library, so this just disables the entire

Is there any reason not to do this?
Attachment (patch.txt): text/x-patch, 848 bytes
Jonathan Wakely | 27 Aug 19:33 2014

[patch] libstdc++/62159 install missing freestanding headers for C++11

C++11 adds several more headers to the minimum requirements for a
freestanding implementation.

Tested x86_64-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 2552 bytes