Jonathan Wakely | 29 May 00:35 2015

[patch] libstdc++/66327 don't pass null pointers to memcmp

std::equal((int*)0, (int*)0, p) and std::equal(p, p, (int*)0) are
valid for any input iterator p, and must not pass a null pointer to

Similarly, std::lexicographical_compare((int*)0, (int*)0, p, q) and
std::lexicographical_compare(p, q, (int*)0, (int*)0) are valid for any
input iterators p and q, and must not pass a null pointer to memcpy.

This is a rather brute force fix, but if noone has any better ideas
I'll commit this to the trunk and 4.9 and 5 branches tomorrow. (I
think it should go on the branches, because 4.9 is known to optimise
away null pointer checks after invalid calls to memcmp like this).

I am not adding tests for these as we have no way to use ubsan in the
testsuite at present. I plan to make that possible, and will go back
and add tests using -fsanitize=undefined for all the recent fixes I've
made for ubsan errors.

Tested powerpc64le-linux.
Attachment (patch.txt): text/x-patch, 1431 bytes
Jonathan Wakely | 22 May 16:15 2015

[patch] libstdc++/66017 Avoid bad casts and fix alignment of _Rb_tree_node<long long>::_M_storage

There are two problems involved in this PR.

First, as Clang's ubsan detects, we are using static_cast to convert
from _Rb_tree_node_base* to _Rb_tree_node<_Val>* in cases where there
is no _Rb_tree_node<_Val> at that address (_M_impl._M_header is just
an _Rb_tree_node_base). That's undefined behaviour, and shows up here
when alignof(_Rb_tree_node_base) != alignof(_Rb_tree_node<_Val>)
because we end up with a misaligned _Rb_tree_node<_Val>* (which we
never dereference, because it's the past-the-end iterator, but it's
still UB to do the cast).

The second problem is that alignof(_Rb_tree_node<long long>) changes
depending on whether it's compiled as c++98 or c++11. This is because
in C++11 mode I replaced the member _M_value_field with uninitialized
storage aligned as alignof(_Val), using __aligned_buffer, but for
targets that define the ADJUST_FIELD_ALIGN target macro it's wrong to
assume that alignof(_M_value_field) == alignof(_Val), because the type
might have weaker alignment when it's a member of a structure. This
means the __aligned_buffer in C++11 mode is not aligned the same as
the _M_value_field member it was meant to replace. Ouch.

The first problem can be fixed by simply removing the casts, I don't
see why we need them. They are there because the _Rb_tree_iterator and
_Rb_tree_const_iterator constructors take a pointer-to-derived, but
then they upcast to pointer-to-base and store that type instead. So if
we just make the constructors take pointer-to-base instead then we
don't need the possibly-invalid casts. This way we only do the
downcast when dereferencing an iterator, which only happens for real
nodes where the downcast is valid, not for _M_impl._M_header.

(Continue reading)

Tony Liu | 21 May 10:28 2015

Question about std::terminate() in __cxa_pure_virtual()


Currently the implementation of __cxa_pure_vitual() function is:
extern "C" void
__cxxabiv1::__cxa_pure_virtual (void)
   writestr ("pure virtual method called\n");
   std::terminate ();

However this version will result to quite large code size of user
programme, if use std::abort() instead of std::terminate(), the code
size drops significantly: 47080 vs 3056 in my case.
In the embedded system, the size of memory are quite limited. Would it
be possible to replace the terminate() by abort(), or replace it just
in some cases (e.g. -fno-exceptions enabled while building libstdc++


Jonathan Wakely | 20 May 19:11 2015

[patch] libstdc++/66078 __make_move_if_noexcept_iterator should return a constant iterator or a move iterator

As discussed in the thread starting at when
__make_move_if_noexcept_iterator decides not to move it returns a
mutable iterator, which can then result in the wrong constructor being
used. This ensures that when not moving we will get a pointer-to-const
which will result in the copy constructor being called.

Tested powerpc64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 6677 bytes
Jonathan Wakely | 14 May 15:28 2015

[patch] libstdc++/66011 Fix various filesystem operations

The PR is due to missing the third argument to open(3) but there are
some other errors in the same function as well as some unimplemented
features, and some bad error handling elsewhere.

The autoconf check for sendfile is intentionally conservative because
some BSDs define a sendfile() function with different semantics (it
can only copy a file to a socket, not another regular file).

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 6156 bytes
Jonathan Wakely | 13 May 18:43 2015

[patch] Constructing std::shared_ptr from an empty std::unique_ptr

Voted in to the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 3258 bytes
Jonathan Wakely | 13 May 15:56 2015

[patch] Add std::raw_storage_iterator::base() member

Voted into the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 2272 bytes
Jonathan Wakely | 13 May 15:54 2015

[patch] std::packaged_task(allocator_arg_t, const A&, F&&) should not be explicit

Voted into the WP in Lenexa.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 939 bytes
Jonathan Wakely | 13 May 14:25 2015

[patch] LWG 2440 std::seed_seq::size() should be noexcept

This was resolved as a defect and voted into the working paper in
Lenexa. As an extension we can also make the default constructor

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 1144 bytes
Jonathan Wakely | 13 May 14:21 2015

[v3 patch] Implement LWG 2466 (allocator_traits::max_size() is stoopid)

We agreed to move this to Ready in Lenexa.

I'd like to see max_size() deprecated, it's useless, but if we can't
do that it might as well not give an impossible answer.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 8 KiB
Jonathan Wakely | 7 May 18:06 2015

TR1 Special Math

Hi Ed,

The C++ committee is considering the
proposal to make C++17 include the contents of ISO 29124:2010 (the
special math functions from TR1 that went into a separate standard,
not into C++11).

What is the status of our TR1 implementation? Is it complete? Good
enough quality to move out of the tr1 sub-dir?

Even if N4437 isn't accepted for C++17 we could move things around to
turn the TR1 code into an iso29124 implementation, do you think that
would make sense?