This patch avoids over-sizing of the container by rather considering the
bucket count hint or potential reservation.
It concerns only the non-multi containers.
* include/bits/hashtable.h
(_Hashtable<>(_InputIterator, _InputIterator, size_t, const _H1&,
const _H2&, const _Hash&, cons
This patch adds noexcept qualification on allocator aware constructors
and fix the one on the default constructor.
* include/bits/hashtable.h
(_Hashtable(_Hashtable&& __ht, __node_alloc_type&& __a, true_type)):
Add noexcept qualification.
(_Hashtable(_Hashtable&&)): Fix noexcept
Simplify local_iterator implementation. It makes local_iterator and
iterator comparable which is used in debug containers.
* include/bits/hashtable_policy.h (_Node_iterator_base()): New.
(operator==(const _Node_iterator_base&, const _Node_iterator_base&)):
Make hidden friend.
(op
H1 used to be a reference to the user Hash, now _Hashtable and unordered
types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful ranged hash functor. We
only use _Mod_range_hashing and _Mask_range_hashing.
Thanks to this simplification _M_buck
This is an implementation of PR 68303.
I try to use this idea as much as possible to avoid computation of hash
codes.
Note that tests are not showing any gain. I guess hash computation must
be quite bad to get a benefit from it. So I am only activating it when
hash code is not cached and/or
On 11/17/19 11:21 PM, Ville Voutilainen wrote:
On Sun, 17 Nov 2019 at 23:15, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and unordered
types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful ranged hash
Hi
I noticed that we are not checking that iterators are not singular
in valid_range. Moreover __check_singular signature for pointers is not
intercepting all kind of pointers in terms of qualification.
I'd like to commit it next week but considering we are in stage 3 I
need proper a
I plan to commit this patch tomorrow.
* include/debug/safe_iterator.h
[__cpp_lib_concepts](_Safe_iterator<>::iterator_concept): Define for
C++20.
François
diff --git a/libstdc++-v3/include/debug/safe_iterator.h b/libstdc++-v3/include/debug/safe_iterator.h
index 685256551d9..abf575186c7
I plan to commit this tomorrow.
But I really wonder if we couldn't just add some __glibcxx_checks_xxx in
std/array ?
* include/debug/array (array<>::fill): Add C++20 constexpr.
(array<>::swap): Likewise.
François
diff --git a/libstdc++-v3/include/debug/array b/libstdc++-v3/include/de
I have a patch for the same location so here is my remark that might
make my patch useless.
Maybe you can even merge it with yours Ed, here it is:
https://gcc.gnu.org/ml/libstdc++/2019-10/msg00072.html
On 11/25/19 10:15 PM, Jonathan Wakely wrote:
On 15/11/19 22:17 -0500, Ed Smith-Rowland via
On 11/26/19 1:21 PM, Jonathan Wakely wrote:
On 26/11/19 12:33 +0100, Stephan Bergmann wrote:
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not
singular in valid_range. Moreover
On 11/26/19 9:49 PM, Stephan Bergmann wrote:
On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had
run the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
I also try -std=gnu++98 and made
On 11/26/19 10:52 PM, Jonathan Wakely wrote:
On 26/11/19 20:07 +0100, François Dumont wrote:
Sure, I am about to do so.
However I wasn't sure about this syntax before the commit so I had
run the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
Hi
Here is a patch to enhance constexpr support in _GLIBCXX_DEBUG. I
work on std::lower_bound/upper_bound to find out if Debug mode is well
prepared. I'll continue on other algos later.
I initially hope that I could count on the compiler for the
valid_range check. But for lower_bound
Hi
Here is a patch to avoid definition of invalid operators on the
Debug mode safe iterator type depending on its category.
Even if it is limited to the Debug mode code I would like to have a
feedback before committing. Especially on the following points:
- _Safe_tagged_iterator: Is
Here is a patch to improve Debug mode safe iterator move semantic.
To summarize where we used to have N mutex locks we now have N - 1.
For instance move constructor used to lock mutex twice, now it only does
it once. Note that move constructor or move assignment operator are
currently
On 10/08/2018 13:26, Ville Voutilainen wrote:
On 10 August 2018 at 13:47, Jonathan Wakely wrote:
Doing a test like this with TSan should be the absolute minimum
required for any change to the mutex locking policy.
Agreed. Concurrency code is something that our test suite is not
well-equipped t
This test fails when using 'make check-debug' because it redefines
_GLIBCXX_DEBUG. Using dg-options fixes this problem.
Committed as trivial.
François
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy/86658.cc b/libstdc++-v3/testsuite/25_algorithms/copy/86658.cc
index 600747a..dd4f7ba 100
Here is the new proposal. It is indeed possible to keep _Safe_iterator
and just add a _Category template parameter to it.
I introduce a friend declaration to access container _Base nested
typedef from the safe iterator.
I review the safe const_iterator constructor from safe iterator. I now
c
This patch implements P0646R1 for Debug mode containers.
It fixes tests:
23_containers/forward_list/operations/remove_cxx20_return.cc
23_containers/forward_list/operations/unique_cxx20_return.cc
23_containers/list/operations/remove_cxx20_return.cc
23_containers/list/operations/unique_cxx20_retur
patch.
On 20/08/2018 22:26, François Dumont wrote:
This patch implements P0646R1 for Debug mode containers.
It fixes tests:
23_containers/forward_list/operations/remove_cxx20_return.cc
23_containers/forward_list/operations/unique_cxx20_return.cc
23_containers/list/operations/remove_cxx20_retu
On 21/08/2018 11:33, Jonathan Wakely wrote:
On 18/08/18 22:31 +0200, François Dumont wrote:
Here is the new proposal. It is indeed possible to keep
_Safe_iterator and just add a _Category template parameter to it.
While this is still a large patch (obviously, because it's changing a
lo
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 12:22, François Dumont wrote:
Hi
Any chance to review this patch ?
François
On 06/06/2018 18:39
Now that _Safe_iterator has been revisited I would like to cleanup its
operators to make them globals and inline friends as much as possible.
This patch transform operator-(const _Safe_iterator<>&, difference_type)
and operator+(const _Safe_iterator<>&, difference_type) into global
namespace o
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all my
attempts to make them inline friends failed. I understand that an
inline friend within a base class is not a very clean design
The last optimizations that get disabled when Debug mode is enable are
the algo specializations for std::deque iterators.
This patch move those algos in std namespace as they should even when
Debug mode is enable so that they get considered even when calls are
made with the namespace qualifica
On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
On 08/28/2018 09:00 PM, Jonathan Wakely wrote:
On 25/08/18 22:44 +0200, François Dumont wrote:
The last optimizations that get disabled when Debug mode is enable
are the algo specializations for std::deque iterators.
This patch move those algos in std namespace as they should even when
Debug
Thanks for all those explanations. It helped me to find the solution.
So here is the final patch with all operators inline friends.
Tested under Linux x86_64.
* include/debug/safe_iterator.h
(_Safe_iterator<_It, _Seq, std::random_access_iterator_tag>::_Self):
New.
(_Safe_iterato
On 05/06/2017 13:31, Jonathan Wakely wrote:
On 04/06/17 22:26 +0200, François Dumont wrote:
Hi
I have eventually adapt the test to all containers and the result
is successful for map/set/unordered_map/unordered_set. It is failing
for deque/list/forward_list/vector/vector.
I even try
On 08/06/2017 15:22, Jonathan Wakely wrote:
Oh dear, we have a compiler bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
And not a recent one !
which takes place only if I call this:
test_type *tmp = ::new(buf._M_addr()) test_type {};
To force default/value init looks like gcc forc
On 12/06/2017 13:57, Jonathan Wakely wrote:
Ok to commit ?
OK, thanks.
Done yesterday.
I guess that considering the compiler bug and rare occasions for this
bug to show up we don't backport.
François
On 12/05/2017 13:03, Jonathan Wakely wrote:
A much simpler (but equivalent) change would be:
--- a/libstdc++-v3/src/c++98/tree.cc
+++ b/libstdc++-v3/src/c++98/tree.cc
@@ -153,6 +153,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/* Static keyword was missing on _Rb_tree_rotate_left.
Export the sym
On 01/06/2017 15:34, Jonathan Wakely wrote:
I would expect the constructor to look like this:
_Bvector_impl()
_GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
: _Bit_alloc_type()
{ }
What happens when you do that?
_Bvector_impl(const _Bit_alloc_type& _
Hi
Here is the patch to default the default and move constructors on
the std::forward_list. Putting a move constructor on _Fwd_list_node_base
helped limiting the code impact of this patch. It doesn't have any side
effect as iterator types using this base type are not defining any move
sem
Hi
Here is the patch to default implementation of std::list default
and move constructors.
I introduce _List_node_header to take care of the move
implementation and also isolate management of the optional list size
storage. I prefer it to usage of _List_node as move constructor
seem
Sorry, it was the wrong patch. Here is the right one.
François
On 06/11/2017 22:17, François Dumont wrote:
Hi
I just committed this as trivial to avoid test to be considered as
unsupported.
Looks like gcc made improvements in optimizations to have this test
now unsuported.
Tested under
Hi
Working on istreambuf_iterator I realized that this iterator would
really benefit from an std::advance overload so here it is.
Tested under Linux x86_64 normal and debug modes, ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h b/libstdc++-v3/inclu
On 10/11/2017 21:57, Jonathan Wakely wrote:
On 09/11/17 22:12 +0100, François Dumont wrote:
Hi
Working on istreambuf_iterator I realized that this iterator
would really benefit from an std::advance overload so here it is.
Tested under Linux x86_64 normal and debug modes, ok to
On 16/11/2017 12:46, Jonathan Wakely wrote:
On 16/11/17 10:57 +, Jonathan Wakely wrote:
On 16/11/17 08:51 +0300, Petr Ovtchenkov wrote:
On Mon, 6 Nov 2017 22:19:22 +0100
François Dumont wrote:
Hi
Any final decision regarding this patch ?
François
https://gcc.gnu.org/ml/libstdc
On 16/11/2017 19:12, Petr Ovtchenkov wrote:
On Thu, 16 Nov 2017 18:40:08 +0100
François Dumont wrote:
On 16/11/2017 12:46, Jonathan Wakely wrote:
Let me be more clear: I'm not going to review further patches in this
area while you two are proposing different alternatives, without
comme
Here is the latest version I plan to commit after validation.
I'd like to keep the change to the money_get/get/[char/wchar_t]/9.cc
tests. At the moment those tests passes only because there is no
operation on the is iterator (like a check for eof). If we add any,
internal _M_buf will be resete
_Node_alloc_type&)): Change parameter to
rvalue-reference.
If you fear abi breaking change I can restore it in a
!_GLIBCXX_INLINE_VERSION section.
François
On 28/08/2017 21:09, François Dumont wrote:
Hi
Any news for this patch ?
It does remove a constru
Here is a patch to fix those failures of the latest report:
UNRESOLVED: 23_containers/map/modifiers/extract.cc compilation failed to
produce executable
FAIL: 23_containers/set/modifiers/extract.cc (test for excess errors)
UNRESOLVED: 23_containers/set/modifiers/extract.cc compilation failed to
Hi
I plan to apply attached patch tomorrow to fix those _GLIBCXX_DEBUG
failures:
FAIL: 23_containers/map/modifiers/insert/dr2354.cc (test for excess errors)
FAIL: 23_containers/multimap/modifiers/insert/dr2354.cc (test for excess errors)
FAIL: 23_containers/unordered_map/insert/dr2354.cc (te
Now backported to branch.
On 24/12/2017 08:55, Jonathan Wakely wrote:
On 19 December 2017 at 21:33, François Dumont wrote:
Hi
I plan to apply attached patch tomorrow to fix those _GLIBCXX_DEBUG
failures:
FAIL: 23_containers/map/modifiers/insert/dr2354.cc (test for excess errors)
FAIL
Hi
Bug confirmed, limited to range insertion on unordered_set and
unordered_map.
I had to specialize _M_insert_range for those containers. Now this
method maintains the theoretical number of elements to insert which is
used only if an insertion takes place.
I also took this opo
Hi
As we are at working on associative containers I'd like to propose this
last patch to remove the copy constructible constraint on the _Compare
functor when it is supposed to be default constructed.
This way the _Compare is built directly at its final place.
* include/bits/stl_tree.h (
On 25/05/2018 21:19, Ville Voutilainen wrote:
On 25 May 2018 at 22:16, Jonathan Wakely wrote:
Why is this patch removing _Compare() calls? That changes the
initialization
of _Compare from value-initialization to default-initialization, which
is a breaking change.
The _Rb_tree_key_compare base
ewise.
(__merge_without_buffer(_BIt, _BIt, _BIt, _Dist, _Dist, _Comp)):
Likewise.
François
On 14/05/2018 22:14, François Dumont wrote:
Any feedback regarding this patch ?
On 02/05/2018 07:26, François Dumont wrote:
Hi
std::rotate already returns the expected iterator so there is no
need for calls t
Hi
Here is this patch again, I consider all your remarks and also made
some changes considering feedback on rbtree patch.
* include/bits/stl_vector.h
(struct _Vector_base<>::_Vector_impl_data): New.
(struct _Vector_base<>::_Vector_impl): Inherit from latter.
(_Vector_base<>
Hi
I'd like to propose this patch to avoid std::distance calls. In a number
of situation in algos we already have the size of the buffer we need so
we shouldn't have to compute it again.
I don't think there is any abi concern for this inline constructor,
isn't there ?
* include/bits/st
On 04/06/2018 23:09, Jonathan Wakely wrote:
On 04/06/18 22:13 +0200, François Dumont wrote:
Hi
I'd like to propose this patch to avoid std::distance calls. In a
number of situation in algos we already have the size of the buffer
we need so we shouldn't have to compute it again.
figures),
the way should provide speedup.
Thanks.
On 24/01/2018 18:23, François Dumont wrote:
Hi
It sounds like a very sensitive change to make but nothing worth figures.
Do you have any bench showing the importance of the gain ?
At least the memory usage optimization is obviou
We reset safe iterator state a lot, quite annoying when debugging.
Comitted as trivial.
2018-06-07 François Dumont
* src/c++11/debug.cc
(_Safe_iterator_base::_M_detach()): Reset state only if needed.
(_Safe_iterator_base::_M_detach_single()): Likewise
Gentle reminder.
On 27/05/2018 19:25, François Dumont wrote:
Still no chance to review it ?
I'd like this one to go in before submitting other algo related patches.
* include/bits/stl_algo.h
(__rotate(_Ite, _Ite, _Ite, forward_iterator_tag))
(__rotate(_Ite, _Ite,
Hi
If not told otherwise I plan to commit attached patch tomorrow evening.
It is adding new Debug checks to find out if an output iterator
will always be reachable while looping on an input range. Note that this
check was already done previously by checking if the iterator was
[in,de]
I'm struggling having a validation for this patch.
As it is a trivial one and to not bother you I plan to commit it
tomorrow if not told otherwise.
François
On 08/06/2018 07:54, François Dumont wrote:
Gentle reminder.
On 27/05/2018 19:25, François Dumont wrote:
Still no chance to r
and why applying the patch in the first place failed.
François
On 13/06/2018 15:24, Jonathan Wakely wrote:
On 13/06/18 13:42 +0200, Paolo Carlini wrote:
Hi,
On 13/06/2018 08:11, François Dumont wrote:
On 12/06/2018 23:26, Martin Sebor wrote:
Bootstrap fails in libstdc++ with the following er
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug mode
performance impact.
So this patch make use of the existing std::__niter_base to get rid
of the debug layer around __gnu_debug::vector<>::iterat
Working on iterator == operator I noticed that a comparison in
_Safe_iterator was inconsistent.
* include/debug/debug.h
(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
Compare __x base iterator with a default initialized iterator of the
same type.
Tested under
On 26/06/2018 18:03, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug
mode performance impact.
So this patch make use o
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain. However I haven't quit on reducing
Debug
Commited attached patch.
It fixes the missing noexcept qualification on a __gnu_debug::vector<>
constructor.
2018-06-27 François Dumont
* include/bits/stl_vector.h
(struct _Vector_base<>::_Vector_impl_data): New.
(struct _Vector_base<>::_Vector_impl): I
On 27/06/2018 22:02, Jonathan Wakely wrote:
On 27/06/18 21:25 +0200, François Dumont wrote:
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it
right thing, no matter the original
iterator type.
I eventually found no issue in the testsuite, despite the
std::equal change. I might have had a local invalid test.
Ok to commit ?
François
On 27/06/2018 22:02, Jonathan Wakely wrote:
On 27/06/18 21:25 +0200, François Dumont wrote
Hi
Here is an updated patch.
Tested under Linux x86_64.
Ok to commit ?
François
On 21/08/2017 21:15, François Dumont wrote:
Following feedback on std::list patch this one had the same problem of
unused code being deleted. So here is a new version.
Ok to commit ?
François
On
On 16/01/2018 01:20, Jonathan Wakely wrote:
On 15/01/18 22:32 +0100, François Dumont wrote:
On 15/01/2018 13:29, Jonathan Wakely wrote:
In fact it introduces a serious regression because of this line:
- vector(vector&& __x) noexcept
- : _Base(std::move(__x)) { }
+
Hi
I'd like to propose this new debug check. Comparing with non-eos
istreambuf_iterator sounds like an obvious coding mistake.
I propose it despite the stage 1 as it is just a new debug check,
it doesn't impact the lib in normal mode.
Tested under Linux x86_64, ok to commit ?
F
On 24/01/2018 18:53, Petr Ovtchenkov wrote:
On Wed, 24 Jan 2018 17:39:59 +0100
François Dumont wrote:
Hi
I'd like to propose this new debug check. Comparing with non-eos
istreambuf_iterator sounds like an obvious coding mistake.
I propose it despite the stage 1 as it is j
As you know, buffered merge is far speed then (split, rotate, and
merge two sub-arrays) (PR c++/83938 gives the profiling figures),
the way should provide speedup.
Thanks.
On 24/01/2018 18:23, François Dumont wrote:
Hi
It sounds like a very sensitive change to make but nothi
Hi
As we just bump version namespace it might be interesting to do the
following change now. What do you think ?
François
diff --git a/libstdc++-v3/include/bits/forward_list.h b/libstdc++-v3/include/bits/forward_list.h
index 56b3ac5..05abd43 100644
--- a/libstdc++-v3/include/bits/forward_
Hi
Here is a patch to fix some pretty printer check errors when
running those tests with _GLIBCXX_DEBUG.
I introduced a special rendered for the std::forward_list iterator
which is similar to the one used for the std::list and so used
inheritance, I hope it is not a problem for Pytho
On 05/02/2018 18:16, Jonathan Wakely wrote:
On 01/02/18 22:48 +0100, François Dumont wrote:
Hi
As we just bump version namespace it might be interesting to do
the following change now. What do you think ?
I'd rather not make the code harder to read in all those places just
f
On 06/02/2018 20:16, François Dumont wrote:
On 05/02/2018 18:16, Jonathan Wakely wrote:
Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the versioned-namespace? Then at least the
conditional code is only in one place.
Yes, __aligned_buff
On 20/02/2018 20:59, Jonathan Wakely wrote:
On 8 February 2018 at 06:10, François Dumont wrote:
On 06/02/2018 20:16, François Dumont wrote:
On 05/02/2018 18:16, Jonathan Wakely wrote:
Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the vers
On 06/03/2018 22:21, Jonathan Wakely wrote:
@@ -575,10 +586,12 @@ class StdDebugIteratorPrinter:
# and return the wrapped iterator value.
def to_string (self):
base_type = gdb.lookup_type('__gnu_debug::_Safe_iterator_base')
+itype = self.val.type.template_argument(0)
On 08/03/2018 19:11, Jonathan Wakely wrote:
This caused a new regression for:
std::forward_list flst;
std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }
$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL: li
On 08/03/2018 19:11, Jonathan Wakely wrote:
This caused a new regression for:
std::forward_list flst;
std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }
$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL: li
Hi
Following PR 78420 patch I realized that we can use similar
technique to have assertions in string_view implementations.
I also rename testsuite files expected to XFAIL as they should have
a trailing '_neg'. It fixes 4 XPASS when run in debug mode
Note that I also try to use
On 20/03/2018 19:20, Jonathan Wakely wrote:
On 17 March 2018 at 09:01, Jonathan Wakely wrote:
Native configuration is x86_64-pc-linux-gnu
=== libstdc++ tests ===
Running target unix/-std=gnu++11/-D_GLIBCXX_ASSERTIONS
=== libstdc++ Summary for
unix/-std=gnu+
On 09/04/2018 02:59 PM, Jonathan Wakely wrote:
template
void
- fill(const _Deque_iterator<_Tp, _Tp&, _Tp*>& __first,
- const _Deque_iterator<_Tp, _Tp&, _Tp*>& __last, const _Tp&
__value)
+ fill(const _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*>&
__first,
+ const _GLI
ng in case the pass int
value do not match the deque value type.
Ok to commit ?
François
On 09/06/2018 10:07 PM, François Dumont wrote:
On 09/04/2018 02:59 PM, Jonathan Wakely wrote:
template
void
- fill(const _Deque_iterator<_Tp, _Tp&, _Tp*>& __first,
- const
at we could get it from here whatever
the mode activated.
François
On 09/07/2018 06:30 PM, François Dumont wrote:
I realized that I was not checking the Debug implementations.
Doing so also have the advantage to show clearly which overload of the
algos is being used. If it is using the correct
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment was
declaring that is to say:
// Return a prime no smaller than n.
_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size is
exceeded, not only when it is reach.
We talk about it a while back.
I've run testsuite several times since I have this patch on my local
copy. Note that when I implemented it the wrong way tests started to
fail so it is clearly having an effect on the generated code.
* include/bits/c++config [__OPTIMIZE__](__glibcxx_assert): Def
On 09/17/2018 11:15 PM, Marc Glisse wrote:
On Mon, 17 Sep 2018, François Dumont wrote:
We talk about it a while back.
I've run testsuite several times since I have this patch on my local
copy. Note that when I implemented it the wrong way tests started to
fail so it is clearly havi
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment
was declaring that is to say:
// Return a prime no smaller than n
On 09/18/2018 08:11 AM, Marc Glisse wrote:
On Tue, 18 Sep 2018, François Dumont wrote:
If your concern is rather that the condition got evaluated which will
eventually slow down execution then I need to check generated code.
Any good link explaining how to have a clear view on the generated
On 09/19/2018 01:07 PM, Jonathan Wakely wrote:
On 18/09/18 22:39 +0200, François Dumont wrote:
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what
?
François
On 09/19/2018 01:07 PM, Jonathan Wakely wrote:
On 18/09/18 22:39 +0200, François Dumont wrote:
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does
mpared to calling empty().
2018-09-28 François Dumont
* include/debug/functions.h
(__foreign_iterator_aux3(const _Safe_iterator<>&, const _InputeIter&,
const _InputIter&, __true_type)): Use empty() rather than begin() ==
end().
François
diff --git a/li
On 09/28/2018 02:01 PM, Jonathan Wakely wrote:
On 25/09/18 22:11 +0200, François Dumont wrote:
I guess it must have something to do with the [] but as I escaped
both I don't understand what's wrong.
You might need to escape them twice, or more ... so that TCL doesn't
try to
Just some code cleanup extending use of C++11 direct initialization.
* include/debug/map.h
(map<>::emplace<>(_Args&&...)): Use C++11 direct initialization.
(map<>::emplace_hint<>(const_iterator, _Args&&...)): Likewise.
(map<>::insert(value_type&&)): Likewise.
(map<>::insert<>
Here is the cleanup version.
* include/bits/stl_tree.h
(_Rb_tree_iterator<>::operator==): Make inline friend.
(_Rb_tree_iterator<>::operator!=): Likewise.
(_Rb_tree_const_iterator<>::operator==): Likewise.
(_Rb_tree_const_iterator<>::operator!=): Likewise.
(operator==(cons
also made sure we use consistent comparison between
iterator/const_iterator in erase and emplace methods.
2018-10-08 François Dumont
* include/debug/list (list<>::cbegin()): Use C++11 direct
initialization.
(list<>::cend()): Likewise.
(list<>::emp
As we talked one day I would like to make all iterator operators global
for consistency. So here is the patch to do so for std::list iterators.
Thanks to this change the operators ==(iterator, const_iterator) and !=
are not necessary anymore, one less ==|!= operator candidate.
* include/b
On 10/09/2018 01:31 PM, Jonathan Wakely wrote:
On 09/10/18 07:25 +0200, François Dumont wrote:
As we talked one day I would like to make all iterator operators
global for consistency. So here is the patch to do so for std::list
iterators.
By "global" you mean "non-member
Same patch as for std::list iterators. I only additionally move doc on
those operators.
I also avoid redefining some typedef that are already defined in
_Fwd_list_base<>.
* include/bits/forward_list.h
(_Fwd_list_iterator<>::operator==): Replace member function with inline
friend.
201 - 300 of 1037 matches
Mail list logo
