Jonathan Wakely | 4 Mar 18:20 2015

[patch] libstdc++/64797 fix handling of incomplete multibyte characters

To fix the non-portable 22_locale/conversions/string/ test I
changed it to use char16_t and char32_t where I can reliably create an
invalid sequence that causes a conversion error. That revealed some
more problems in the Unicode conversion utilities, fixed by this patch
and verified by the new tests.

Most of the changes in are just defining convenience
constants and inline functions, but there are some minor bugs fixed in
UTF-16 error handling too.

Tested x86_64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 17 KiB
Fan You | 4 Mar 09:22 2015

[GSoC] unimplemented TS entries


My name is Fan You. I am a ETC master student from CMU.

I have 3 ideas regarding gsoc 2015:

a) I found 4 unimplemented Technical Specifications at

- C++ Dynamic Array
- Invocation type traits, but dropping function_call_operator
- Polymorphic memory resources
- Extending shared_ptr to support arrays

I'd like to work on C++ Dynamic Array first, then finish others if I
have enough time.

b) After searching the mailing list I found 2 extra ideas:
- rewrite regex <>
- Rb tree node recycling patch

Do you actually need people to finish those?


Jonathan Wakely | 2 Mar 18:51 2015

[patch] libstdc++/65279 fix scoped_allocator_adaptor assignment

std::scoped_allocator_adaptor declares a move constructor but not a
copy assignment operator, which means the copy assignment operator is
defined as deleted, and so scoped_allocator_adaptor<A...> is not
CopyAssignable. (This seems to be exactly what the standard requires,
but that's clearly a defect in the standard and I've reported it).

This is a regression on all branches since 4.7 (because 4.7 didn't
implement the final rules about deleting the copy assignment).

Tested x86_64-linux, committed to trunk so far, with backports for 4.8
and 4.9 to follow.

Attachment (patch.txt): text/x-patch, 3761 bytes
Tim Shen | 24 Feb 07:55 2015

Any variant class?

Hi there,

I'm recently refactoring <regex>, and one of the problem needs to be
solved is stack overflow due to deep recursion.

I plan to solve this by using a heap allocated stack. Ideally it will
be `std::stack<_Variant<...>>` or `std::unique_ptr<_Variant<...>[]>`.
I don't think we have an existing variant class that can be used?

If there's no, I'm gonna write one. Is there any benefit of making a
boost::variant-ish one, or otherwise I can design my own interface?



Tim Shen

Tim Shen | 19 Feb 06:25 2015

Regex backend refactoring/rewriting?

There're three unresolved bugs for C++11 <regex>: std::regex matches
right to left, not leftmost longest C++11 regex
resource exhaustion Regex collate
matching not working

For the third one, I've put my thought there, since I'm not quite sure
what should be done;

Additionally, I noticed that our POSIX executer is not conforming:

    #include <regex>
    #include <iostream>

    using namespace std;

    int main() {
        cmatch m;
        cout << regex_search("aaaaaaaa", m, regex("a*(a*)",
regex_constants::extended)) << "\n";
        for (const auto& it : m) {
            cout << it << "\n";

(Continue reading)

Francois Fayard | 15 Feb 10:07 2015

std::vector : integer overflow in size()


I am puzzled by the result of std::vector<char>::max_size() on the n = 32 and n = 64 bits system I have tested.
The result is 2^n − 1. To me, the libstdc++ can't handle vectors whose size are bigger than 2^(n-1) - 1. Let
me explain why.

Every implementation of std::vector<T> that I know of, libstdc++ included, has three members of type T*:
begin_, end_, capacity_. begin_ points to the first value of the vector and end_ points to the one after the
last. The size() method takes the difference of those pointers which is of type std::ptrdiff_t (which is
then casted to a std::size_t). This type is a signed integer of n bits. Therefore, it can not store the
integer 2^n − 1, but only up to 2^(n − 1) − 1. That's why I would expect this last number for max_size().
Is it a bug or something that I overlooked?
Paweł Tomulik | 13 Feb 15:11 2015

[PATCH] missing return statement in basic_regex::assign(basic_regex&&)


the header file  <bits/regex.h> of libstdc++-v3 of gcc-4.9 is missing
return statement in the implementation of
basic_regex::assign(basic_regex&&). This is about line 619. The minimal
example to reproduce this bug is the following:

#include <regex>
int main()
  std::regex re;
  return EXIT_SUCCESS;

When compiled with clang and run it produces SIGILL:

ptomulik <at> tea:$ clang++ -std=c++11 -g -O0 -o test test.cpp
ptomulik <at> tea:$ ./test

I attach patch created with git against the "gcc-4_9_2-release" tag.

Best regards.


Paweł Tomulik, tel. (22) 234 7925
Instytut Techniki Lotniczej i Mechaniki Stosowanej
Politechnika Warszawska

(Continue reading)

Tom Cook | 5 Feb 11:30 2015

Re: UTF-16 streams

Confirmed that this also fails with gcc trunk (as of about 5AM UTC
today).  The stack trace is the same.  Is there something I need to do
to use the ctype<char16_t> you've added?

Actually I can't spot that template specialisation in the trunk code
(ie `grep -r 'ctype.*char16_t.*'` returns no matches, either in the
source or in $HOME/gcc-5.0/include).  If you could have a look and see
if it's sitting in a workspace somewhere, I'd be grateful.


On Thu, Feb 5, 2015 at 5:37 PM, Tom Cook <tom.k.cook <at>> wrote:
> Thanks, Jonathan.  I'm currently building the GCC trunk to see where it gets me.
> I'm not at all certain, by the way, that the standard requires this -
> I don't have ready access to a copy.
> As a side note, it would be useful if
> mentioned whether the build
> works using eg 'make -j 5'.
> Regards,
> Tom
> On Thu, Feb 5, 2015 at 3:15 PM, Jonathan Wakely <jwakely.gcc <at>> wrote:
>> On 4 February 2015 at 23:38, Tom Cook wrote:
>>> A more specific question: is providing a specialisation of std::ctype
>>> (ie std::ctype<char16_t>) the right way to fix this?
(Continue reading)

Tom Cook | 4 Feb 08:07 2015

UTF-16 streams


I was a bit surprised to find that this doesn't work:

#include <sstream>
#include <string>

int main() {
    std::basic_stringstream<char16_t> ss;
    std::basic_string<char16_t> s(u"Hello, world.");
    ss << s;
    ss >> s;

Specifically, the last line of main causes a std::bad_cast to be
thrown, with the following stack trace:

(gdb) bt
#0  0x00007ffff7b2cea0 in __cxa_throw () from
#1  0x00007ffff7b832e2 in std::__throw_bad_cast() ()
   from /usr/lib/x86_64-linux-gnu/
#2  0x0000000000403840 in std::__check_facet<std::ctype<char16_t> > (__f=0x0)
    at /usr/include/c++/4.8/bits/basic_ios.h:49
#3  0x0000000000402899 in std::basic_istream<char16_t,
std::char_traits<char16_t> >::sentry::sentry (this=0x7fffffffdbc7,
__in=..., __noskip=false)
    at /usr/include/c++/4.8/bits/istream.tcc:60
#4  0x0000000000401b31 in std::operator>><char16_t,
std::char_traits<char16_t>, std::allocator<char16_t> > (__in=...,
(Continue reading)

Tim Shen | 3 Feb 22:26 2015

[libstdc++/61601] Throws an exception on stack overflow?

Currently std::regex uses recursion for traversing its internal NFA.

1) the user input string for being matched is too long;
2) there're too many NFA states,

stack overflow will happen. 2) can be avoided (as we already did) by
limiting total number of NFA states. For 1) however, I think throwing
std::regex_error::error_stack is appropriate, but I don't know if we
can do that without manually keeping track of the recursion depth.

I'm typically asking: is there a portable way to set a temporary
thread local stack overflow (SIGSEGV?) handler when matching starts,
and reset it back when matching ends/quits ?

Alternatively, I can rewrite it to non-recursive, but it will use a
stack container on the heap and I'm not sure if it will be slowed


Tim Shen

Jonathan Wakely | 2 Feb 19:14 2015

Re: [PATCH][Testsuite] isctype test fails for newlib.

On 2 February 2015 at 18:03, Matthew Wahab wrote:
> Updated patch attached and changelog below.

Looks good, OK for trunk - thanks for fixing it.