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 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 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
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):
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
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
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(_
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
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
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 12/4/18 3
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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/
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 remove
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.
*
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
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
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
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.
*
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
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
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
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
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
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_iterat
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
cleanup
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
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:
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 cha
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
() + (__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
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
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:
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.
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
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.
*
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<>::emplace<&g
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.
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.
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 handle them
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
?
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
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
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/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/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
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):
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.
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 Debug
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 _Deque_ite
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
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.
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
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
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
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
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
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
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
lot!) I
.
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_return.cc
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
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
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
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
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
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:
Hi
It has already been noticed that there are 2 ebo helpers in the
lib. Here is a patch to use 1.
* include/bits/ebo_helper.h: New.
* include/Makefile.am: Add latter.
* include/Makefile.in: Regenerate.
* include/bits/hashtable_policy.h: Adapt.
*
Ping.
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 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
Hi
Any chance to review this patch ?
François
On 06/06/2018 18:39, François Dumont wrote:
Hi
I review and rework this proposal. I noticed that the same idea to
limit buffer size within inplace_merge also apply to stable_sort.
I also change the decision when buffer is too
This patch improves the assertion message generated in 2
__gnu_debug::string constructors giving the assertion context thanks to
the __FUNCTION__ macro.
Was:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/string:56:
const _CharT* __gnu_debug::__check_string(const
Hi
I plan to commit attached patch to fix the __gnu_debug::string
undefined macro.
Is it ok the way I used some tests to now validate
__gnu_debug::string on check-debug ?
François
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index
r<>, _Sequence>&)): New.
Ok to commit ?
On 02/07/2018 13:57, Jonathan Wakely wrote:
On 01/07/18 21:20 +0200, François Dumont wrote:
Here is a new proposal between yours and mine.
It is still adding a function to wrap what __niter_base unwrap, I
called it __nwrap_iter for
the 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
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
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 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 mode
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
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
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
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
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 review
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
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, _Ite
501 - 600 of 1024 matches
Mail list logo
