Re: Rb_tree constructor optimization

On Fri, May 18, 2018 at 6:45 PM, Jonathan Wakely wrote: > On 17/05/18 16:10 +0100, Jonathan Wakely wrote: >> >> On 15/05/18 07:30 +0200, François Dumont wrote: >>> >>> Here it is again even more simplified. Should I backport the Debug mode >>> fix to 8 branch ? >> >> >> Yes,

Re: Rb_tree constructor optimization

On 17/05/18 16:10 +0100, Jonathan Wakely wrote: On 15/05/18 07:30 +0200, François Dumont wrote: Here it is again even more simplified. Should I backport the Debug mode fix to 8 branch ? Yes, please do backport the include/debug/* changes.     * include/bits/stl_tree.h    

Re: Rb_tree constructor optimization

On 15/05/18 07:30 +0200, François Dumont wrote: Here it is again even more simplified. Should I backport the Debug mode fix to 8 branch ? Yes, please do backport the include/debug/* changes.     * include/bits/stl_tree.h     (_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New.    

Re: Rb_tree constructor optimization

On 11/05/2018 14:16, Jonathan Wakely wrote: On 06/05/18 16:06 +0200, François Dumont wrote: Here is the rework of this patch. On 02/05/2018 13:49, Jonathan Wakely wrote: There's no changelog entry with the patch, so to recap, the changes are: - noexcept specifications are automatically

Re: Rb_tree constructor optimization

On 06/05/18 16:06 +0200, François Dumont wrote: Here is the rework of this patch. On 02/05/2018 13:49, Jonathan Wakely wrote: There's no changelog entry with the patch, so to recap, the changes are: - noexcept specifications are automatically deduced instead of being  stated explicitly. I

Re: Rb_tree constructor optimization

Here is the rework of this patch. On 02/05/2018 13:49, Jonathan Wakely wrote: There's no changelog entry with the patch, so to recap, the changes are: - noexcept specifications are automatically deduced instead of being  stated explicitly. I simplified this part, it is not deduced anymore

Re: Rb_tree constructor optimization

On 02/05/2018 13:49, Jonathan Wakely wrote: On 01/05/18 21:56 +0200, François Dumont wrote: Hi If not told otherwise I'll commit attached patch tomorrow. Please do not commit it, see below. Already discussed here: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html There's no

Re: Rb_tree constructor optimization

On 01/05/18 21:56 +0200, François Dumont wrote: Hi If not told otherwise I'll commit attached patch tomorrow. Please do not commit it, see below. Already discussed here: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html There's no changelog entry with the patch, so to recap, the

Re: Rb_tree constructor optimization

On 02/05/18 00:47 +0300, Ville Voutilainen wrote: On 2 May 2018 at 00:28, Jakub Jelinek wrote: On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote: On 1 May 2018 at 22:56, François Dumont wrote: > Hi > > If not told otherwise I'll commit

Re: Rb_tree constructor optimization

On 2 May 2018 at 00:28, Jakub Jelinek wrote: > On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote: >> On 1 May 2018 at 22:56, François Dumont wrote: >> > Hi >> > >> > If not told otherwise I'll commit attached patch tomorrow. >> >> >> Commit

Re: Rb_tree constructor optimization

On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote: > On 1 May 2018 at 22:56, François Dumont wrote: > > Hi > > > > If not told otherwise I'll commit attached patch tomorrow. > > > Commit it where? The 8.1 release is not out yet, so we shouldn't be > pushing

Re: Rb_tree constructor optimization

On 1 May 2018 at 22:56, François Dumont wrote: > Hi > > If not told otherwise I'll commit attached patch tomorrow. Commit it where? The 8.1 release is not out yet, so we shouldn't be pushing new stuff onto trunk yet. Nor should we push such stuff into the release branch.

Rb_tree constructor optimization

Hi If not told otherwise I'll commit attached patch tomorrow. Already discussed here: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html François diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h index a4a026e..2b8fd27 100644 ---

Re: Rb_tree constructor optimization

Hi     Any feedback regarding this patch ? Thanks, François On 14/09/2017 22:04, François Dumont wrote: I realized there was no test on the noexcept qualification of the move constructor with allocator. I added some and found out that patch was missing a noexcept qualification at _Rb_tree

Re: Rb_tree constructor optimization

I realized there was no test on the noexcept qualification of the move constructor with allocator. I added some and found out that patch was missing a noexcept qualification at _Rb_tree level. Here is the updated patch fully tested, ok to commit ? François On 13/09/2017 21:57, François

Re: Rb_tree constructor optimization

On 08/09/2017 17:50, Jonathan Wakely wrote: Since we know __a == __x.get_allocator() we could just do: _Rb_tree(_Rb_tree&& __x, _Node_allocator&&, true_type) noexcept(is_nothrow_move_constructible<_Rb_tree_impl<_Compare>>::value) : _M_impl(std::move(__x._M_impl)) { } This means

Re: Rb_tree constructor optimization

On 28/08/17 21:12 +0200, François Dumont wrote: Hi Here is the always equal allocator optimization for associative containers. Tested under Linux x86_64. * include/bits/stl_tree.h (_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New. (_Rb_tree(_Rb_tree&&,

Rb_tree constructor optimization

Hi Here is the always equal allocator optimization for associative containers. Tested under Linux x86_64. * include/bits/stl_tree.h (_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New. (_Rb_tree(_Rb_tree&&, _Node_allocator&&, std::true_type)): New.