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
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
ension 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_deallocate_node(_
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
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
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
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
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
const_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
in _ReuseOr
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):
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 having
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
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
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
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):
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
: 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 wrote
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.
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
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
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
I had miss some occurences of __bucket_hint to replace with
__bucket_count_hint so here is a new version.
Ok to commit with the simple ChangeLog entry below ?
On 5/21/19 7:42 AM, François Dumont wrote:
Here is a simplified form.
Rename variables and cleanup comments.
* include/bits
Hi
Here is a patch to enhance the _Hashtable extract node API and fix
a FIXME request.
The enhancement to the extract node Api is that extract(const
key_type&) do not call extract(const_iterator) anymore. Doing so we had
to loop again through bucket nodes to find the previous node
dbf5edf0
}
iterator "__last" @ 0x0x7fffdbf5ea10 {
type =
std::move_iterator<__gnu_cxx::__normal_iteratorstd::default_delete >*, std::vectorstd::default_delete >> > > (mutable iterator);
state = past-the-end;
references sequence with type
'std::
On 6/5/19 6:22 PM, Jonathan Wakely wrote:
On 04/06/19 19:19 +0200, François Dumont wrote:
Hi
Here is a patch to enhance the _Hashtable extract node API and
fix a FIXME request.
The enhancement to the extract node Api is that extract(const
key_type&) do not call ext
On 5/29/19 12:06 AM, Jonathan Wakely wrote:
On 23/05/19 07:39 +0200, François Dumont wrote:
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
Thanks for making this opt-in.
it and there is a detectable issue with libbacktrace then I
the performance test didn't make it, I'll re-submit it in
another patch more dedicated to small size optimization.
François
On 5/31/19 1:44 PM, Jonathan Wakely wrote:
Re https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00903.html
On 15/10/18 22:46 +0200, François Dumont wrote:
I started
Here is what I come up with.
Regarding allocation in print_function I would also prefer to avoid it.
But this patch also aim at creating a backtrace_state object in case of
UB so the alloc is perhaps not so important. I can't use string_view as
I need to modify it to display only a part of
On 12/21/18 9:57 PM, Jonathan Wakely wrote:
On 29/10/18 07:06 +0100, François Dumont wrote:
Hi
Some feedback regarding this patch ?
Sorry this got missed, please resubmit during stage 1.
You haven't CC'd the original patch author (chang jc) to give them a
chance to comment on your
On 6/18/19 12:54 PM, Jonathan Wakely wrote:
On 18/06/19 07:52 +0200, François Dumont wrote:
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok to commit ? Feel free to do it if you prefer, I'll do so at end of
Europe day otherwise.
diff
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok to commit ? Feel free to do it if you prefer, I'll do so at end of
Europe day otherwise.
François
On 6/17/19 12:28 PM, Jonathan Wakely wrote:
On 07/06/19 18:39 +0200, François Dumont
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
Here is a new proposal which I think take into account all your remarks.
I discovered the great "%.*s" printf format so I was able to do some
cleanup on the function name without any allocation.
I also agree that counting the '>' or '<' is not reliable so I remove
this and limit the cleanup
Hi
Still influenced by PR 68303 this patch:
- Extend usage of find within other methods. It simplify code and will
allow to implement the PR in less places if we decide to do so.
- Get rid of several bucket index comparison for non-unique key
containers this way we have less hash code
On 6/19/19 12:47 AM, Jonathan Wakely wrote:
On 18/06/19 22:42 +0200, François Dumont wrote:
On 6/18/19 12:54 PM, Jonathan Wakely wrote:
On 18/06/19 07:52 +0200, François Dumont wrote:
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok
*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
I wanted
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
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
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
On 5/21/19 10:51 PM, Jonathan Wakely wrote:
On 21/05/19 22:47 +0200, François Dumont wrote:
On 5/21/19 3:50 PM, Jonathan Wakely wrote:
On 20/05/19 21:41 -0700, Thomas Rodgers wrote:
With the addition of "-ltbb" to the v3_target_compile flags (so as to,
you know, actually try t
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' being
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
it and there is a detectable issue with libbacktrace then I generate a
compilation error. I want to avoid users defining it but having no
backtrace in the end in the debug assertion.
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 is a node
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 ?
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
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
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
On 5/21/19 3:50 PM, Jonathan Wakely wrote:
On 20/05/19 21:41 -0700, Thomas Rodgers wrote:
With the addition of "-ltbb" to the v3_target_compile flags (so as to,
you know, actually try to link tbb).
Tested x86_64-linux, committed to trunk.
This didn't work, I still get a FAIL for every pstl
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
.
(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
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
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
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
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
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:
Hi
S
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
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
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
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
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.
*
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
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 commit
(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'm
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
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
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
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'
/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 is why I'd
iterator<>&)): Likewise.
(__equal_aux(const _Safe_iterator<>&,
const _Safe_iterator<>&, const _Safe_iterator<>&)): Likewise.
François
On 9/27/19 6:45 PM, Jonathan Wakely wrote:
On 27/09/19 18:24 +0200, François Dumont wrote:
On 9/27/19 2:11 PM,
On 9/27/19 2:28 PM, Jonathan Wakely wrote:
On 09/09/19 20:34 +0200, François Dumont wrote:
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
On 9/27/19 2:11 PM, Jonathan Wakely wrote:
On 19/09/19 22:27 +0200, François Dumont wrote:
Hi
I start working on making recently added constexpr tests to work
in Debug mode.
The attached patch seems to be necessary for that, right?
On my side I had done this, almost the same
On 9/26/19 3:20 PM, Jonathan Wakely wrote:
Fix data race when _Safe_iterator_base::_M_detach() runs concurrently
with
the _Safe_container_base destructor.
PR libstdc++/91910
* src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load pointer
atomically and lock the mutex before
On 9/30/19 11:03 AM, Jonathan Wakely wrote:
On 28/09/19 23:12 +0200, François Dumont wrote:
Here is what I just commited.
Thanks. In my branch I had a lot more _GLIBCXX20_CONSTEXPR additions
in the debug mode headers. Is it not needed on __check_singular,
__foreign_iterator etc. ?
Yes, I
This is a missing part of C++20 P1023 for __debug::array.
Implement C++20 p1023 - constexpr comparison operators for
__debug::array.
* include/debug/array: Add C++20 constexpr to comparison operators.
* testsuite/23_containers/array/tuple_interface/get_debug_neg.cc: Adapt
On 9/27/19 1:24 PM, Jonathan Wakely wrote:
On 20/09/19 07:08 +0200, François Dumont wrote:
I already realized that previous patch will be too controversial to
be accepted.
In this new version I just implement a real memmove in __memmove so
A real memmove doesn't just work backwards
On 9/27/19 1:00 PM, Jonathan Wakely wrote:
On 19/07/19 23:37 +0200, François Dumont wrote:
It sounds reasonable to overload std::copy_n for istreambuf_iterator.
I wonder whether it's worth doing:
#if __cplusplus >= 201703L
if constexpr (is_same_v<_OutputIterator, _CharT*>)
From what I understood from recent fix the unordered containers need to
be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers node
values are moved as soon as _M_assign is called with a rvalue reference
to the source container.
Additionnaly this patch
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.
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
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&,
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
This patch simplifies a number of implementations.
It tries as much as possible to avoid computing hash code. This is
especially true for the erase implementation in case of multi keys.
* include/bits/hashtable_policy.h (_Map_base<>::at): Use
_Hashtable<>::find.
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
This is the begining of a patch series for _Hashtable
Initial patch to clarify code. I was tired to see true/false or
true_type/false_type without knowing what was true/false.
I also made code more consistent by chosing to specialize methods
through usage of __unique_keys_t/__multi_keys_t
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
When applying:
2019-11-26 François Dumont
* include/debug/array (array<>::fill): Add C++20 constexpr.
(array<>::swap): Likewise.
I forgot to adapt some line numbers.
Committed as trivial.
François
diff --git a/libstdc++-v3/testsuite/23_containers/array/tup
Last patch of my series following this one:
https://gcc.gnu.org/ml/libstdc++/2019-12/msg00028.html
This time I work on std::copy_n/std::copy overloads for
istreambuf_iterator so that it works also for deque iterators and
transparently in _GLIBCXX_DEBUG mode.
* include/bits/stl_algo.h
to submit afterward.
Note that this patch is based after this one:
https://gcc.gnu.org/ml/libstdc++/2019-10/msg00072.html
François
On 9/25/19 6:44 AM, François Dumont wrote:
Ping ?
On 9/9/19 8:34 PM, François Dumont wrote:
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n
After completing execution of all tests I had to fix implementation of
__check_singular to get only 1 return statement.
On 12/2/19 8:31 PM, François Dumont wrote:
Hi
Here is a patch to enhance constexpr support in _GLIBCXX_DEBUG. I
work on std::lower_bound/upper_bound to find out
Following:
https://gcc.gnu.org/ml/libstdc++/2019-12/msg00028.html
I've done the same kind of work on std::lexicographical_compare algo.
I had to make the internal lexicographical_compare functions return int
rather than bool cause with bool you can't use a chunck based approach
unless you
This patch also require an update of the printers.py file.
Here is an updated version.
François
On 11/17/19 9:42 PM, François Dumont wrote:
This is the begining of a patch series for _Hashtable
Initial patch to clarify code. I was tired to see true/false or
true_type/false_type without
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace
usage outside std namespace. Let me know if it was intentional.
* src/c++11/random.cc: Add _GLIBCXX_BEGIN_NAMESPACE_VERSION and
501 - 600 of 1024 matches
Mail list logo