9
Morwenn
*De :* libstdc++-ow...@gcc.gnu.org de la
part de François Dumont
*Envoyé :* mercredi 19 juin 2019 19:32
*À :* libstd...@gcc.gnu.org; gcc-patches
*Objet :* Deque fiil/copy/move/copy_backward/move_backward/equal
overloads
Hi
This patch fix a minor problem with usage of std::move_if_noexcept.
We use it to move node content if move construtor is noexcept but we
eventually use the allocator_type::construct method which might be
slightly different. I think it is better to check for this method
noexcept qualifica
On 12/4/18 3:38 PM, Jonathan Wakely wrote:
On 04/12/18 07:45 +0100, François Dumont wrote:
Hi
This patch fix a minor problem with usage of std::move_if_noexcept.
We use it to move node content if move construtor is noexcept but we
eventually use the allocator_type::construct method which
Hi
Here is the integration of libbacktrace to provide the backtrace on
_GLIBCXX_DEBUG assertions.
I decided to integrate it without impacting the build scripts.
Users just need to install libbacktrace and once done _GLIBCXX_DEBUG
will look for it and start using it if supported. The
gt;()(_Arg&&)): Likewise.
* libstdc++-v3/testsuite/util/testsuite_allocator.h
(CustomPointerAlloc<>::allocate(size_t, pointer)): Replace by...
(CustomPointerAlloc<>::allocate(size_t, const_void_pointer)): ...this.
François
On 11/29/18 7:08 AM, François Dumont wrote:
I am unclea
eck for noexcept qualification of Value type move
constructor and it doesn't really make sens to check for
alloc::construct when we eventually call allocValue>::construct.
I'll submit this officially once back in stage 1.
François
On 12/4/18 10:43 PM, François Dumont wrote:
On
Hi
I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.
The std::pair move default constructor might not move both first
and second member. If any is not moveable it will just copy it. And then
the noexcept qualification of the copy
On 12/20/18 9:04 AM, Ville Voutilainen wrote:
On Thu, 20 Dec 2018 at 08:29, François Dumont wrote:
Hi
I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.
The std::pair move default constructor might not move both first
and
s extension and I haven't tried yet.
François
On 12/16/18 2:16 PM, François Dumont wrote:
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_dealloc
On 12/21/18 9:29 PM, Jonathan Wakely wrote:
On 16/12/18 14:16 +0100, François Dumont wrote:
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_dea
On 12/21/18 10:03 PM, Jonathan Wakely wrote:
On 21/12/18 22:47 +0200, Ville Voutilainen wrote:
On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely
wrote:
> I also explcitely define BACKTRACE_SUPPORTED to 0 to make sure
>libstdc++ has no libbacktrace dependency after usual build.
I'm concerned
And here are the lexicographical_compare overloads.
I am submitting this seperately from the others cause some might argue
that it is a lot of code for a scope limited to the moment to unsigned
byte types.
I had to overload __lexicographical_compare_aux here cause the
std::lexicographical_co
Committed as trivial.
* testsuite/util/testsuite_iterators.h
(bidirectional_iterator_wrapper): Fix type comment.
(random_access_iterator_wrapper): Likewise.
François
diff --git a/libstdc++-v3/testsuite/util/testsuite_iterators.h b/libstdc++-v3/testsuite/util/testsuite_iterators.h
in
Hi
I am eventually working on another implementation to acheive the
same result with less changes and codes. I think you'll prefer this one.
So don't spend any time on this patch proposal, a new one will come
in a couple of days.
François
Hi
I am having this warning:
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/util/testsuite_performance.h:170:
attention: ignoring return value of « void* malloc(size_t) » declared
with attribute « warn_unused_result » [-Wunused-result]
170 | malloc(0); // Needed for some implementat
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The improvements are:
- activation of algo specialization for __gnu_debug::_Safe_iterator (w/o
_GLIBCXX_DEBUG mode)
- activation of algo specialization for _Deque_iterator even if mixed
with ano
Hi
This is the next part of:
https://gcc.gnu.org/ml/libstdc++/2019-09/msg00048.html
This time it is to improve behavior of std::lexicographical_compare for
deque or safe iterators.
To do so I had to make lc internal implementation return int rather than
bool otherwise it is impossible to ha
Here is the patch to improve _Safe_iterator<>::_M_get_distance_to
implementation.
I introduced a new _Distance_precision __sp_sign_max_size for occasions
where we can't find out the exact size of a range but still get the max
size of it. Thanks to this the performance tests are much bette
Hi
I start working on making recently added constexpr tests to work in
Debug mode.
It appears that the compiler is able to detect code mistakes pretty
well as long we don't try to hide the code intention with a defensive
approach. This is why I'd like to propose to replace '__n > 0'
On 9/19/19 10:27 PM, François Dumont wrote:
Hi
I start working on making recently added constexpr tests to work
in Debug mode.
It appears that the compiler is able to detect code mistakes
pretty well as long we don't try to hide the code intention with a
defensive approach. This
This patch makes extensive use of C++11 direct init in
__debug::forward_list.
Doing so I also try to detect useless creation of safe iterators in
debug implementation. In __debug::forward_list there are severals but I
wonder if it is worth fixing those. Most of them are like this:
void
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this change in the patch ?
* include/bits/stl_bvector.h (_Bit_iterator_base::operator==): Replace
member m
() + (__first.base() - _Base::cbegin()), this };
The latter version was building 2 safe iterators and incrementing 1 with
the additional debug check inherent to such an operation whereas the new
version just build 1 safe iterator with directly the expected offset.
2018-10-15 François Dumont
* include
On 10/15/2018 11:58 AM, Jonathan Wakely wrote:
On 11/10/18 22:46 +0200, François Dumont wrote:
This patch makes extensive use of C++11 direct init in
__debug::forward_list.
Doing so I also try to detect useless creation of safe iterators in
debug implementation. In __debug::forward_list
On 10/15/2018 11:36 AM, Jonathan Wakely wrote:
On 12/10/18 18:25 +0200, François Dumont wrote:
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this change in
I started considering PR libstdc++/68303.
First thing was to write a dedicated performance test case, it is the
unordered_small_size.cc I'd like to add with this patch.
The first runs show a major difference between tr1 and std
implementations, tr1 being much better:
std::tr1::unordered_set
On 10/15/2018 12:10 PM, Jonathan Wakely wrote:
On 15/10/18 07:23 +0200, François Dumont wrote:
This patch extend usage of C++11 direct initialization in
__debug::vector and makes some calls to operator - more consistent.
Note that I also rewrote following expression in erase method
On 10/15/2018 12:07 PM, Jonathan Wakely wrote:
On 09/10/18 07:11 +0200, François Dumont wrote:
Here is the communication for my yesterday's patch which I thought
svn had failed to commit (I had to interrupt it).
Similarly to what I've done for associative containers here is a
clea
I've just reverted the controversial changes.
2018-10-18 François Dumont
Partial revert.
2018-10-08 François Dumont
* include/debug/list (list<>::cbegin()): Use C++11 direct
initialization.
(list<>::cend()): Likewise.
(list<>::erase(const_i
Current build of libstdc++ with --enable-symvers=gnu-versioned-namespace
fails (at least under Linux) because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
from
../../../../../git/libstdc++-v3/src/c+
As reported in another mail a symbol is missing.
This patch update test framework so that the problem is obvious and fix it.
* testsuite/util/testsuite_containers.h
(forward_members_unordered<>::forward_members_unordered
(const value_type&)): Add local_iterator pre and post increment
I plan to commit the attached patch this week if not told otherwise.
This is to generalize usage of C++11 direct initialization in unordered
containers.
It also avoids a number of safe iterator instantiations.
* include/debug/unordered_map
(unordered_map<>::begin()): Use C++11 direct
On 10/18/2018 10:34 PM, Jonathan Wakely wrote:
On 18/10/18 22:12 +0200, François Dumont wrote:
Current build of libstdc++ with
--enable-symvers=gnu-versioned-namespace fails (at least under Linux)
because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu
On 10/23/2018 11:52 AM, Jonathan Wakely wrote:
On 22/10/18 22:45 +0200, François Dumont wrote:
I plan to commit the attached patch this week if not told otherwise.
Looks good.
This is to generalize usage of C++11 direct initialization in
unordered containers.
It also avoids a number of
Some tests dg-prune-output regex need to be adapted to pass when
versioned namespace is activated.
I preferred to add the version namespace in the regex rather than
removing namespace qualification. Let me know if you would prefer the
other approach.
* testsuite/23_containers/deque/48101
On 10/25/18 1:16 PM, Jonathan Wakely wrote:
On 24/10/18 21:30 +0200, François Dumont wrote:
Some tests dg-prune-output regex need to be adapted to pass when
versioned namespace is activated.
I preferred to add the version namespace in the regex rather than
removing namespace qualification
Hi
Some feedback regarding this patch ?
Thanks,
François
On 8/21/18 10:34 PM, François Dumont wrote:
I missed a test that was failing because of this patch. So I revert a
small part of it and here is the new proposal.
Tested under Linux x86_64, ok to commit ?
François
On 24/07/2018
Following Marc Glisse change to ignore _M_start offset I wanted to go a
little step further and just remove it in _GLIBCXX_INLINE_VERSION mode.
I also fix a regression we already fixed on mainstream std::vector
regarding noexcept qualification of move constructor with allocator.
And I impleme
Running some tests in C++98 show that the error checked by following
tests are those of the C++11 mode.
This patch add target c++11 so that those tests are ignored in previous
mode.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
Add target c++11.
*
testsuite/23
Running tests in C++98 mode show that I had forgotten a 'return *this;'
in _Bvector_impl_data::operator=.
So here is the patch again.
On 10/30/18 7:28 AM, François Dumont wrote:
Following Marc Glisse change to ignore _M_start offset I wanted to go
a little step further and just re
amp;)): Adapt.
(vector::_M_initialize(size_type)): Adapt.
* testsuite/23_containers/vector/bool/cons/noexcept_move_construct.cc:
Add check.
Tested under Linux x86_64 w/o versioned namespace, w/o C++98 mode.
Ok to commit ?
François
On 10/30/18 10:59 PM, Jonathan Wakely wrote:
On 30/10/
Here is a patch similar to what has been done to other containers like
std::vector.
It optimizes the swap operation, the allocator extended move constructor
and some other methods where I just bypass intermediate calls.
I reproduced the noexcept qualification on _Deque_impl_data/_Deque_impl
Here is the patch submitted by John and now fully tested.
PR libstdc++/87872
* include/debug/safe_sequence.tcc
(_Safe_sequence<>::_M_transfer_from_if): Skip transfer to self.
Is it fine to commit it now ?
François
diff --git a/libstdc++-v3/include/debug/safe_sequence.tcc b/libstdc+
While working on a hashtable enhancement I noticed that we are not using
the correct method to deallocate node if the constructor throws in
_ReuseOrAllocNode operator(). I had to introduce a new
_M_deallocate_node_ptr for that as node value shall not be destroy again.
I also check other places
When doing some debugging session I noticed that the
__gnu_cxx::throw_allocator doubles all lookup on both insert and erase.
Using map::insert result and erasing the found iterator avoids this
double lookup.
* include/ext/throw_allocator.h
(annotate_base::insert(void*, size_t)): Use i
Oops, it was not the tested patch. Here it is.
On 11/12/18 7:43 AM, François Dumont wrote:
When doing some debugging session I noticed that the
__gnu_cxx::throw_allocator doubles all lookup on both insert and erase.
Using map::insert result and erasing the found iterator avoids this
double
onst_void_pointer)): ...this.
* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
check.
François
On 11/10/18 10:40 PM, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate node if the constructor throws
i
On 11/19/18 1:34 PM, Jonathan Wakely wrote:
On 10/11/18 22:40 +0100, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate node if the constructor throws
in _ReuseOrAllocNode operator(). I had to introduce a new
There a memory leak when move assigning between 2 instances with
different bucket count and non-propagating and unequal allocator
instances (see new test03).
I reduced code duplication to fix the issue as 1 of the 2
implementations was fine.
* include/bits/hashtable.h (_Hashtable<>::_M_r
Tests have shown a regression. I was building the _ReuseOrAllocNode
instance too early, node ownership was transfered but was still owned by
_Hashtable instance.
This new version pass all tests.
Ok to commit ?
François
On 11/19/18 10:23 PM, François Dumont wrote:
There a memory leak when
I eventually called the new method _M_assign_elements.
And yes, tracker_allocator was enough.
Committed on trunk for the moment.
François
On 11/26/18 1:12 PM, Jonathan Wakely wrote:
On 24/11/18 22:58 +0100, François Dumont wrote:
---
a/libstdc++-v3/testsuite/23_containers/unordered_set
On 11/27/18 11:00 PM, Jonathan Wakely wrote:
On 27/11/18 22:31 +0100, François Dumont wrote:
I eventually called the new method _M_assign_elements.
Perfect.
And yes, tracker_allocator was enough.
Great.
Committed on trunk for the moment.
Great, thanks.
Please note that GCC 7.4 RC1 is
I am unclear about this patch, is it accepted ?
On 11/19/18 10:19 PM, François Dumont wrote:
On 11/19/18 1:34 PM, Jonathan Wakely wrote:
On 10/11/18 22:40 +0100, François Dumont wrote:
While working on a hashtable enhancement I noticed that we are not
using the correct method to deallocate
Hi
Any feedback regarding this patch ?
Thanks
On 5/14/19 7:46 AM, François Dumont wrote:
Hi
This is the patch on vector to:
- Optimize sizeof in Versioned namespace mode. We could go one step
further by removing _M_p from _M_finish and just transform it into an
offset but it is a
merge.cc: New.
* testsuite/performance/25_algorithms/stable_sort.cc: Rework to allow
execution with different memory constraints.
Ok to commit ?
François
On 6/9/19 4:27 PM, François Dumont wrote:
On 12/21/18 9:57 PM, Jonathan Wakely wrote:
On 29/10/18 07:06 +0100, François Dumont wrote:
Ping ?
On 6/19/19 7:32 PM, François Dumont wrote:
I wanted to implement Debug overloads for those already existing
overloads but then realized that those algos could be generalized.
This way we will benefit from the memmove replacement when operating
with C array or std::array or std::vector
Since commit 5d3695d03b7bdade9f4d05d2b those tests are failing.
* testsuite/23_containers/unordered_map/48101_neg.cc: Adapt dg-error
after PR libstdc++/85965 fix.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/4810
As we adopted the sized deallocation in the new_allocator why not doing
the same in _Temporary_buffer<>.
* include/bits/stl_tempbuf.h (__detail::__return_temporary_buffer):
New.
(~_Temporary_buffer()): Use latter.
(_Temporary_buffer(_FIterator, size_type)): Likewise.
Tested w/o ac
Got it, it is my PR 68303 patch which was introducing this regression. I
fix it to restore those assertions.
You'll see once the awaiting hashtable patches are in...
On 7/18/19 12:18 PM, Jonathan Wakely wrote:
On 18/07/19 07:41 +0200, François Dumont wrote:
Since c
(2nd sent attempt as text this time.)
Good spot, fixed with attached patch, committed as trivial.
2019-07-19 François Dumont
* include/bits/stl_tempbuf.h (__detail::__return_temporary_buffer): Fix
sized deallocation size computation.
On 7/19/19 9:46 PM, Morwenn Ed wrote:
If I'
It sounds reasonable to overload std::copy_n for istreambuf_iterator.
* include/bits/stl_algo.h (copy_n(istreambuf_iterator<>, _Size,
_OIte)):
New declaration.
* include/bits/streambuf_iterator.h (istreambuf_iterator<>): Declare
std::copy_n for istreambuf_iterator of char types
Hi
I consider the implementation to decide to invalidate iterators or
not. As nodes are not deallocated and only slghtly impacted during the
rehash process I consider that they shouldn't be invalidated appart from
the local iterators. I should have just consider the Standard.
Here is
Hi
PR 89477 fixes haven't been applied to the Debug mode. Here it is
to fix the different deduction.cc tests.
PR libstdc++/89477
* include/debug/map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
* include/debug/multimap.h (multimap): Likewis
Hi
This is a patch I already proposed in another thread but I review
it and moreover there is now a PR associated so I am submitting it as a
brand new one.
So working on PR 68303 I noticed that one of the performance issue
of current implementation is that initial sizing of buckets i
Hi
This patch allows to run pretty printer tests in _GLIBCXX_DEBUG
mode. If accepted we could even integrate the pretty printers tests
within the check-debug target like it is done for the check target.
* python/libstdcxx/v6/printers.py (add_one_template_type_printer):
Add type p
Hi
This is another attempt to make adapter iterator types operators
undefined when underlying iterator type doesn't support it. For the
move_iterator it is rather easy and even already done for the operator-
so I just generalize it to comparison operators. It doesn't cover all
operators o
.
(test02): Likewise.
(test03): Likewise.
I plan to commit it this evening if not told otherwise.
François
On 5/6/19 3:04 PM, redi at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277
--- Comment #4 from Jonathan Wakely ---
(In reply to François Dumont from comment
Here is a patch to reduce number of operators exposed at std namespace
scope.
* include/bits/stl_deque.h
(_Deque_iterator<>::operator+(difference_type)): Make hidden friend.
(_Deque_iterator<>::operator-(difference_type)): Likewise.
(operator==(const _Deque_iterator<>&, const _De
Thanks for the tip, nice to know.
Attached patch applied.
François
On 5/8/19 8:28 PM, Jonathan Wakely wrote:
On 08/05/19 18:50 +0200, François Dumont wrote:
Here is a patch to reduce number of operators exposed at std
namespace scope.
* include/bits/stl_deque.h
(_Deque_iterator
Hi
Patch similar to the one I just apply for deque iterator including
NRVO copy ellision fix.
* include/bits/stl_bvector.h
(operator==(const _Bit_iterator_base&, const _Bit_iterator_base&)):
Make hidden friend.
(operator<(const _Bit_iterator_base&, const _Bit_iterator_base&
Hi
This patch implements a number of simplifications and optimizations
already done to other containers like std::vector
- Default default and move constructors
- The std::swap optimization
- The construction always equal allocator optimization
- Shortcuts on method calls.
I remove
On 5/10/19 3:59 PM, Jonathan Wakely wrote:
On 10/05/19 14:40 +0100, Jonathan Wakely wrote:
On Thu, 9 May 2019 at 06:49, François Dumont wrote:
Hi
Patch similar to the one I just apply for deque iterator including
NRVO copy ellision fix.
* include/bits/stl_bvector.h
(operator
Hi
This is the patch on vector to:
- Optimize sizeof in Versioned namespace mode. We could go one step
further by removing _M_p from _M_finish and just transform it into an
offset but it is a little bit more impacting for the code.
- Implement the swap optimization already done on main s
On 5/10/19 3:38 PM, Jonathan Wakely wrote:
This seems generally OK, but ...
On Fri, 10 May 2019, 05:59 François Dumont wrote:
I remove several _M_map != nullptr checks cause in current
implementation it can't be null. I have several patches following this
one to support it but in
On 5/15/19 5:37 PM, Jonathan Wakely wrote:
François,
I noticed that _Hash_code_base and _Hashtable_base have a number of
member functions which are overloaded for const and non-const:
const _Equal&
_M_eq() const { return _EqualEBO::_S_cget(*this); }
_Equal&
_M_eq() { return _EqualEB
Hi
Let's apply this resolution first before moving forward with the
std::deque implementation.
Move from state of allocators (LWG2593)
* include/bits/stl_deque.h
(_Deque_base(_Deque_base&&, false_type)): Remove.
(_Deque_base(_Deque_base&&, true_type)): Remove.
(_Deque_b
2 other tests needed to be adapted in 21_strings. Attached patch applied.
2019-05-17 François Dumont
Move from state of allocators (LWG2593)
* include/bits/stl_deque.h
(_Deque_base(_Deque_base&&, false_type)): Remove.
(_Deque_base(_Deque_base&&, tru
atch): Remove.
[__cplusplus >= 201103L](_M_assign_dispatch): Remove.
[__cplusplus >= 201103L](_M_insert_dispatch): Remove.
* testsuite/23_containers/deque/allocator/default_init.cc: New.
Tested under Linux x86_64.
Ok to commit ?
François
On 5/10/19 3:38 PM, Jonathan Wakely wro
Hi
I got tired of '__n' being used in _Hashtable for many different
purposes: node, bucket, bucket count, bucket hint. It makes the code
difficult to read. This code makes sure that __n is a node except is
some very limited use cases where the method name is clear enough to
tell what __n
Hi
std::deque is supposed to be like a double-queue that you can attack
from front and back. But currrently its implementation makes it behave
differently when starting from a fresh deque. If push_back then all goes
well, it is copy/move to the current internal 'node'. If push_front then
a
On 5/17/19 10:24 PM, Jonathan Wakely wrote:
On 17/05/19 18:19 +0200, François Dumont wrote:
Hi
I got tired of '__n' being used in _Hashtable for many different
purposes: node, bucket, bucket count, bucket hint. It makes the code
difficult to read. This code makes sure that __n
On 5/20/19 1:14 PM, Jonathan Wakely wrote:
- r1->deallocate(p, 2);
+ r1->deallocate(p, 2, alignof(char));
+ __builtin_printf("%d\n", (int)bytes_allocated);
Was this last line really intended to be added ?
Here is a simplified form.
Rename variables and cleanup comments.
* include/bits/hashtable_policy.h
* include/bits/hashtable.h
Ok to commit ?
François
On 5/17/19 10:24 PM, Jonathan Wakely wrote:
On 17/05/19 18:19 +0200, François Dumont wrote:
Hi
I got tired of '__n&#
I was writing a test which needed to override the std::nothrow
versions of the operator new and delete to control get_temporary_buffer
behavior and noticed that it is inconsistent with
release_temporary_buffer in terms of new/delete operators.
Grepping for other std::nothrow usages I f
Hi
Any final decision regarding this patch ?
Note that __std_a namespace is optional, I can remove this change
from the patch if you want.
François
On 18/07/2016 21:25, François Dumont wrote:
On 13/07/2016 19:45, Jonathan Wakely wrote:
On 22/06/16 22:05 +0200, François Dumont
Attached patch applied then.
I had to regorganize things a little now that some pieces have been
integrated in 71181 patch.
2016-05-24 François Dumont
* include/bits/c++config (_GLIBCXX14_USE_CONSTEXPR): New.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy
On 25/05/2016 16:01, Jonathan Wakely wrote:
On 22/05/16 17:16 +0200, François Dumont wrote:
Hi
To fix 71181 problem I propose to change how we deal with reserve
called with pivot values that is to say prime numbers. Now
_M_next_bkt always return a value higher than the input value. This
Hi
I was trying to play with tuple implementation and was annoyed by
repetition of _Head type when instantiating _Head_base so I thought
about this patch.
How do you like it ?
I still need to run tests, will do before commit, ok ?
François
Index: include/std/tuple
==
Fully tested and committed to trunk.
François
On 06/06/2016 12:17, Jonathan Wakely wrote:
On 02/06/16 23:00 +0200, François Dumont wrote:
Hi
I was trying to play with tuple implementation and was annoyed by
repetition of _Head type when instantiating _Head_base so I thought
about this
Hi
Here is the patch I already proposed to introduce the debug light
mode for vector and deque containers.
It also simplify some internal calls.
* include/debug/debug.h
(__glibcxx_requires_non_empty_range, __glibcxx_requires_nonempty)
(__glibcxx_requires_subscript): Move..
/hash_policy/prime_rehash.cc: New.
* testsuite/23_containers/unordered_set/hash_policy/rehash.cc:
Fix indentation.
Tested under Linux x86_64.
François
On 25/05/2016 22:48, François Dumont wrote:
On 25/05/2016 16:01, Jonathan Wakely wrote:
On 22/05/16 17:16 +0200, François Dumont wrote
Hi
Here is the patch to limit burden on compiler in finding out what
is the right method to call eventually when we already know it.
This patch doesn't show all indentation fixes I will also commit.
* include/bits/stl_deque.h
(std::deque<>::operator=): Call _M_assign_aux.
On 14/06/2016 13:22, Jonathan Wakely wrote:
On 13/06/16 21:49 +0200, François Dumont wrote:
Hi
I eventually would like to propose the attached patch.
In tr1 I made sure we use a special past-the-end iterator that
makes usage of lower_bound result without check safe.
I'm con
onempty check.
(std::vector<>::back()): Likewise.
(std::vector<>::pop_back()): Likewise.
(std::vector<>::swap(vector&)): Add allocator check.
Tested under Linux x86_64.
François
On 13/06/2016 12:21, Jonathan Wakely wrote:
On 08/06/16 22:53 +0200, François Dumont wrote:
.
* testsuite/23_containers/unordered_set/hash_policy/rehash.cc:
Fix indentation.
On 15/06/2016 10:29, Jonathan Wakely wrote:
On 14/06/16 22:34 +0200, François Dumont wrote:
const unsigned long* __next_bkt =
- std::lower_bound(__prime_list + 5, __prime_list +
__n_primes, __n
Hi
Here is eventually the so long promized patch to introduce Debug
algos similarly to Debug containers.
Why such an evolution:
- More flexibility, debug algos can be used explicitely without
activating Debug mode.
- Performance: Debug algos can get rid of Debug layer on top of
conta
Debug mode array had simply been forgotten when fixing zero-size
swap method as part of swappable traits implementation.
* include/debug/array (array<>::swap): Fix noexcept qualificaton for
zero-size array.
Tested under Linux x86_64 debug mode.
François
Index: include/debug/arr
Trivial attached patch applied to fix this regression. I am surprised
that gcc had not detected it.
2016-06-27 François Dumont
PR libstdc++/71640
* include/bits/hashtable.h: Remove _Unique_keya parameter in _Insert
friend declaration.
On 26/06/2016 18:21, pinskia at gcc dot
tor tests run so far.
François
On 20/06/2016 09:42, Jonathan Wakely wrote:
On 19/06/16 10:21 +0200, François Dumont wrote:
On 16/06/2016 22:21, Jonathan Wakely wrote:
On 16/06/16 21:27 +0200, François Dumont wrote:
Very nice improvement. Could also benefit to other containers,
especially std::d
Hi
Here is the last patch I will propose for istreambuf_iterator.
This is mostly to remove the mutable keyword on _M_sbuf.
To do so I had to reset _M_sbuf in valid places that is to say
constructors and increment operators. Despite that we might still have
eof iterators with _M_sbu
401 - 500 of 1064 matches
Mail list logo
