Hi
While working on something else on libstdc++ I started having a
test failing because of the missing comma overload protection in
deque.tcc. So I looked for other similar places in the code and here is
a patch to fix the places I found.
Let me know if it is still time to commit.
F
Hi
If not told otherwise I'll commit attached patch tomorrow.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
François
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index a4a026e..2b8fd27 100644
--- a/libstdc++-v3/include
Hi
Here is the patch I eventually would like to commit.
Tested under Linux x86_64, ok for trunk ?
François
On 17/04/2018 22:34, François Dumont wrote:
Yes, I also think there is no rush to fix this issue.
I had already written a test for a different purpose using the
Hi
std::rotate already returns the expected iterator so there is no
need for calls to std::advance/std::distance.
Tested under Linux x86_64, ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index e10a692..9c1b2d4 100644
---
On 02/05/2018 13:49, Jonathan Wakely wrote:
On 01/05/18 21:56 +0200, François Dumont wrote:
Hi
If not told otherwise I'll commit attached patch tomorrow.
Please do not commit it, see below.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
There
Here is the rework of this patch.
On 02/05/2018 13:49, Jonathan Wakely wrote:
There's no changelog entry with the patch, so to recap, the changes
are:
- noexcept specifications are automatically deduced instead of being
stated explicitly.
I simplified this part, it is not deduced anymore ex
Hi
Here is the 1st patch of a series to improve Debug Mode feedback.
This patch add the content of __PRETTY_FUNCTION__ in the debug
assertion output.
Tested under Linux x86_64.
I'll commit tomorrow if not told otherwise.
* include/debug/formatter.h (_Error_formatter::_M_
Hi
This is to fix what is reported as the pretty function in case of
debug assertion failure in the range constructor.
Result looks like this:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188:
In function:
std::__debug::vector<_Tp, _Allocator>::vector(
Hi
Here is the patch to add backtrace info to debug assertion failure
output.
Example:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188:
In function:
std::__debug::vector<_Tp, _Allocator>::vector(_InputIterator,
_InputIterator, const _Allocator&) [
Here is a patch to teach _Parameter type about special iterator types so
that it improves final output.
It also get rid of the debug layer when possible so that failure output
is cleaner. Debug mode is already transparent to users there is no need
to show the Debug types in the output.
Here
On 08/05/2018 17:27, Jonathan Wakely wrote:
On 07/05/18 22:20 +0200, François Dumont wrote:
Hi
Here is the patch to add backtrace info to debug assertion
failure output.
Example:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188:
In function:
std
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 to std::advance/std::distance.
Tested under Linux x86_64, ok to commit ?
François
On 11/05/2018 14:16, Jonathan Wakely wrote:
On 06/05/18 16:06 +0200, François Dumont wrote:
Here is the rework of this patch.
On 02/05/2018 13:49, Jonathan Wakely wrote:
There's no changelog entry with the patch, so to recap, the changes
are:
- noexcept specifications are automati
On 15/05/2018 18:56, Jonathan Wakely wrote:
As I said in the bugzilla PR, these assertions are all to catch our
own mistakes, not user error.
If we're comfortable the code is correct then we should remove them.
Should we wait until near the end of stage 1, to get more time with
these checks in
u.org/bugzilla/show_bug.cgi?id=85845
François Dumont changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gn
big insertion.
The fix is simple. A call to _M_need_rehash rather than
_M_bkt_for_elements/_M_next_bkt automatically initialize the rehash
policy considering the current number of elements and buckets in the
container.
2014-08-07 François Dumont
* include/bits/hashtable.h
to the Standard.
So here is the patch again even if a little bit simplified.
Regarding the doc I try to put information in Doxygen comments this way
we do not need to maintain another page for that.
2014-08-12 François Dumont
* include/bits/hashtable.h: Make use of the inter
On 12/08/2014 21:39, Marc Glisse wrote:
On Tue, 12 Aug 2014, François Dumont wrote:
Based on your feedbacks I think we should stay with just targeting
good QoI by not allocating on default construction. As I said the
noexcept qualification would need to not conform strictly to the
quite a burden. Do
you think we shall do so now ?
2014-08-14 François Dumont
* include/bits/hashtable_policy.h (_Prime_rehash_policy): Qualify
constructor
noexcept.
(_Hash_code_base<>): All specialization default constructible if
possible.
(_Hashtable_base&l
Any news regarding this proposal ?
Thanks
François
On 30/07/2014 23:39, François Dumont wrote:
Hi
Now that patch on testsuite allocator is in I would like to
reactivate this one. Here it is again.
See previous answer below regarding modification of
_M_begin/_M_cbegin
t we could document it ourself
next to the code rather than in a distinct file.
François
On 14/08/2014 21:22, François Dumont wrote:
On 13/08/2014 11:50, Jonathan Wakely wrote:
Yes you can, it's conforming to replace a (non-virtual) member function
with default arguments by two or more m
__get_distance can be simplified to only take one type of iterator,
_M_valid_range is not a template method anymore. I also modified
_BeforeBeginHelper so that it also generates consistent comparisons of
iterators.
2013-11-08 François Dumont
* include/debug/safe_iterator.h (_BeforeBeginHelper
Hi
At the time of writing unordered container debug mode, local
iterator didn't have the bucket information. Now they have so I would
like debug mode to use it rather than duplicating the information.
2013-11-21 François Dumont
* include/debug/safe_local_itera
Hi
Following N3644 discussion thread here is a patch proposal to
remove default zero-initialization of unordered containers iterator. I
also took the time to remove default zero-init of nodes _M_nxt pointer.
2013-11-25 François Dumont
* include/bits/hashtable_policy.h
Hi
I just committed this trivial bug fix.
Shall I go ahead and apply it to 4.9 branch too ?
2014-10-05 François Dumont
PR libstdc++/63456
* include/bits/hashtable.h (_M_uses_single_bucket(__bucket_type*)):
Test
the parameter.
* testsuite/23_containers
On 05/10/2014 21:37, Paolo Carlini wrote:
Hi,
On 10/05/2014 08:50 PM, François Dumont wrote:
+#include
Seems redundant.
Thanks!
Paolo.
Yes it is and in fact I had remove it before the real commit, I should
have update the patch.
François
On 05/10/2014 22:54, Marc Glisse wrote:
On Sun, 5 Oct 2014, François Dumont wrote:
I took a look at PR 61217 regarding pop_heap complexity guarantee.
Looks like we have no test to check complexity of our algos so I
start writing some starting with the heap operations. I found no
issue
On 06/10/2014 23:05, Daniel Krügler wrote:
2014-10-06 23:00 GMT+02:00 François Dumont :
On 05/10/2014 22:54, Marc Glisse wrote:
On Sun, 5 Oct 2014, François Dumont wrote:
I took a look at PR 61217 regarding pop_heap complexity guarantee.
Looks like we have no test to check complexity of
Hi
Here is a proposal to fix the issue with iterators which do not
expose lvalue references when dereferenced. I simply chose to detect
such an issue in c++11 mode thanks to the is_lvalue_reference meta function.
2014-10-15 François Dumont
PR libstdc++/63500
* include/bits
iterator adapters comes
in-between. I hope one day to detect invalid usages even in this context.
2014-10-16 François Dumont
PR libstdc++/63500
* include/debug/functions.h (__foreign_iterator_aux2): Do not check for
foreign iterators if input iterators returns rvalue reference.
new
operator. I wonder if some test using it really have the expected behavior.
I also tests other algos that try to use a buffer and didn't found
any issue. Those algos however can't be simplified like stable_partition.
2014-10-16 François Dumont
PR libstdc++/61107
* in
Then I think we need this patch which also fix other issues.
2014-10-22 François Dumont
* testsuite/25_algorithms/make_heap/complexity.cc: Add missing test
variable.
* testsuite/25_algorithms/sort_heap/complexity.cc: Likewise and use
log2.
* testsuite/25_algorithms
h the hint which wouldn't match the Standard so no
noexcept qualification at the moment.
Tested under Linux x86_64.normal debug and profile modes.
2014-06-03 François Dumont
* include/bits/hashtable.h: Make use of the internal single bucket to
limit allocation as long as contain
For the testsuite allocator I though that for an internal allocator
used in our tests it was ok. But alright, I will make it better and
compatible with SimpleAllocator.
On 11/06/2014 14:02, Jonathan Wakely wrote:
Index: include/bits/stl_tree.h
=
. Doing so I realized
that move_assign_neg.cc tests were not accurate enough as they needed a
non move propagating allocator and the uneq_allocator were not
explicitly non propagating.
2014-06-21 François Dumont
* testsuite/util/testsuite_allocator.h
(tracker_allocator_counter::allocate
take a personality parameter. Doing so I
realized that move_assign_neg.cc tests were not accurate enough as
they needed a non move propagating allocator and the uneq_allocator
were not explicitly non propagating.
2014-06-21 François Dumont
* testsuite/util/testsuite_allocator.h
On 26/06/2014 12:33, Jonathan Wakely wrote:
The _GLIBCXX_USE_NOEXCEPT macro expands to nothing in C++03 mode, so
you might as well omit it in the #else branch.
OK for trunk if you make the tracker_allocator comment correct.
Thanks!
Committed with:
// An allocator facade that intercepts
On 27/06/2014 21:48, Paolo Carlini wrote:
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm revertin
On 26/06/2014 13:31, Jonathan Wakely wrote:
On 25/06/14 21:56 +0100, Jonathan Wakely wrote:
The other adds an RAII type to help manage pointers obtained from
allocators. The new type means I can remove several ugly try-catch
blocks that are all very similar in structure and have been bothering
m
On 14/05/2015 15:47, Jonathan Wakely wrote:
Reported by Nathan and fixed by his patch. I added the tests.
Tested powerpc64le-linux, committed to trunk. This should be
backported too.
While backporting to debug and profile mode I noticed that those
constructors were not the only missing ones.
Ok, I just commit fixing some other lines length except those having a
long hyperlink, I didn't want to break those.
François
On 16/05/2015 21:32, Jonathan Wakely wrote:
On 16/05/15 11:39 +0200, François Dumont wrote:
On 14/05/2015 15:47, Jonathan Wakely wrote:
Reported by Nathan and
On 03/05/2015 22:19, François Dumont wrote:
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base<> or ju
Hello
Is it ok ?
François
On 04/05/2015 22:31, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3
On 20/05/2015 12:19, Jonathan Wakely wrote:
On 20/05/15 11:17 +0100, Jonathan Wakely wrote:
On 04/05/15 22:31 +0200, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message
On 29/04/2015 17:22, Jonathan Wakely wrote:
I think this covers all the places in the library where we do:
++i, ++j
Tested powerpc64le-linux, committed to trunk.
I just committed 2 missing places in debug mode.
2015-05-23 François Dumont fdum...@gcc.gnu.org>
PR libstdc++/64
On 23/05/2015 13:19, François Dumont wrote:
On 29/04/2015 17:22, Jonathan Wakely wrote:
I think this covers all the places in the library where we do:
++i, ++j
Tested powerpc64le-linux, committed to trunk.
I just committed 2 missing places in debug mode.
2015-05-23 François Dumont fdum
?
2015-02-19 François Dumont
* include/debug/debug.h ([_GLIBCXX_DEBUG_ASSERT,
_GLIBCXX_DEBUG_PEDASSERT, _GLIBCXX_DEBUG_ONLY]): Move definition...
* include/debug/assertions.h: ...here, new.
* include/debug/formatter.h
(struct _Error_formatter::_Is_iterator_value_type): New
On 25/05/2015 20:41, Jonathan Wakely wrote:
On 25/05/15 15:31 +0200, François Dumont wrote:
Hi
This is a patch to clean the debug mode code.
I have introduced a new debug header, assertions.h, so that
headers that only need _GLIBCXX_DEBUG_ASSERT do not have to include
the big debug.h
Hi
Here is a patch to add heterogeneous lookup to alternative modes.
To do so I had to expose __is_transparent as __has_is_transparent to
avoid confilct with existing __is_transparent. Should I put it in
__detail namespace ?
* include/bits/stl_tree.h (_Rb_tree<>::__is_transparent<>):
On 01/06/2015 22:09, Jonathan Wakely wrote:
On 01/06/15 22:04 +0200, François Dumont wrote:
Hi
I can't find how to fix 61347 for alternative modes. I started
with debug mode by providing a forward declaration for safe iterator
type which return to the __distance on normal iterator bu
On 04/06/2015 14:41, Jonathan Wakely wrote:
On 03/06/15 21:56 +0200, François Dumont wrote:
Hi
Here is a patch to add heterogeneous lookup to alternative modes.
Excellent.
To do so I had to expose __is_transparent as __has_is_transparent to
avoid confilct with existing __is_transparent
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes):
Delete.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer even if behind a
reverse_iterator or move_iterator, might help compiler to optimize code,
no ? If not,
With the patch this time.
On 22/04/2015 21:39, François Dumont wrote:
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy
On 27/04/2015 13:55, Jonathan Wakely wrote:
On 22/04/15 22:10 +0200, François Dumont wrote:
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer ev
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base<> or just two overloads of
__miter_base()?)
Definit
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/functions.h:213:
error: function requires a valid iterator ra
quality.cc is very basic and just reflect
enhancement following Marc's comment.
2015-05-05 François Dumont
* include/bits/functional_hash.h
(std::__detail::_Lowest_power_of_two): New.
(std::hash<_Tp*>::operator()): Use latter.
* testsuite/20_util/hash/quality.cc (pointer_q
On 08/05/2015 10:02, Richard Biener wrote:
On Wed, May 6, 2015 at 10:10 PM, François Dumont wrote:
Hi
Following Marc Glisse comment #4
on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 I would like to
propose this enhancement to the hash functor for pointers. It simply gets
rid of
quality lower order bits.
On 8 May 2015 at 21:18, François Dumont wrote:
On 08/05/2015 10:02, Richard Biener wrote:
On Wed, May 6, 2015 at 10:10 PM, François Dumont
wrote:
Hi
Following Marc Glisse comment #4
on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 I would like to
propos
Hello
As we are at doing some evolution in the ABI I would like to take
the opportunity to merge branch libstdcxx_so_7-2. The first fix was
about a messages facet issue. So here is the version for the trunk which
is the one from the branch plus management of the charset part. This way
mes
On 24/11/2014 01:23, Jonathan Wakely wrote:
On 24/11/14 00:13 +0100, François Dumont wrote:
Hello
As we are at doing some evolution in the ABI I would like to take
the opportunity to merge branch libstdcxx_so_7-2. The first fix was
I don't think we want to merge everything, but
locales installed. There are
some failures but not coming from this patch, will surely be the subject
of another mail.
2014-11-28 François Dumont
DR libstdc++/13631
* include/bits/codecvt.h (__get_c_locale): New.
* config/locale/gnu/messages_member.h, messages_member.cc: Prefer
Hi
Here is another proposal that consider all your remarks except one.
I finally prefer to go with std::vector of pointers. Dynamically
allocating Catalog_info allow to avoid numerous copies of locale when we
find this pointer from the catalog info.
On 28/11/2014 11:49, Jonathan Wakely
So here is another proposal with all your remarks implemented.
2014-12-02 François Dumont
DR libstdc++/13631
* include/bits/codecvt.h (codecvt): friend class
std::messages.
(codecvt): friend class
std::messages.
* config/locale/gnu/messages_member.h
(messages
On 18/03/2015 19:16, Jonathan Wakely wrote:
Preparing this patch reminded me that we currently have two copies of
the Catalog_info and Catalogs code in the unnamed namespace in
config/locale/gnu/messages_members.cc, one using the old string and
one using the new. We should really alter the code
Hi
This is a patch to:
- Enhance __get_distance to get a better feedback about distance between
iterators so that we can take sharper decision about what is right or
not. This function is now aware about safe iterators and leverage on
those a little like std::distance does with C++ 11 list::i
On 16/06/2015 22:45, Jonathan Wakely wrote:
> On 16/06/15 22:18 +0200, François Dumont wrote:
>> On 12/06/2015 01:22, Jonathan Wakely wrote:
>>> This fixes two test failures when the default compiler mode is
>>> -std=gnu++14
>>>
>>> FAIL: 25_algor
Hi
2 experimental tests are failing in debug mode because
__do_str_codecvt is sometimes taking address of string front() and
back() even if empty. It wasn't use so not a big issue but it still
seems better to avoid. I propose to rather use string begin() to get
buffer address. I kept operator&
On 22/06/2015 17:10, Jonathan Wakely wrote:
> On 20/06/15 12:59 +0100, Jonathan Wakely wrote:
>> On 20/06/15 12:03 +0200, François Dumont wrote:
>>> Hi
>>>
>>> 2 experimental tests are failing in debug mode because
>>> __do_str_codecvt is sometimes
Hello
Is this one ok ?
François
On 12/06/2015 19:11, François Dumont wrote:
> Hi
>
> This is a patch to:
>
> - Enhance __get_distance to get a better feedback about distance between
> iterators so that we can take sharper decision about what is right or
> not.
On 22/06/2015 17:10, Jonathan Wakely wrote:
> On 20/06/15 12:59 +0100, Jonathan Wakely wrote:
>> On 20/06/15 12:03 +0200, François Dumont wrote:
>>> Hi
>>>
>>> 2 experimental tests are failing in debug mode because
>>> __do_str_codecvt is sometimes
Hi
During a recent discussion on Reflector about max_load_factor some
pointed that libstdc++ has not the constant complexity as imposed by the
Standard in Table 103 because we try to respect the new factor by
potentially rehashing the container. This patch fix this problem by
adopting VS Stand
.
2015-07-05 François Dumont
* include/bits/stl_algobase.h (__miter_base): Move...
* include/bits/cpp_type_traits.h: ...here.
* include/debug/functions.h (__foreign_iterator_aux): Use latter.
* testsuite/23_containers/vector/debug/insert7_neg.cc: New.
Tested undex linux x86_64.
Ok
it ok then to commit attached patch to do the same for debug mode ?
And also for profile mode later when I have it ready (this WE I think) ?
2015-01-22 François Dumont
* include/debug/stl_map.h (map::find<>,
map::lower_bound<>, map::upper_bound<>, map::equal_range&
also surprised that it is not using enable_if, IMHO it makes
the code clearer. Here is a proposal to use both extended to the debug
mode too.
François
On 22/01/2015 03:07, Jonathan Wakely wrote:
On 21/01/15 23:30 +0100, François Dumont wrote:
+#if __cplusplus > 201103L
+ templ
ing I wanted to make something like in bits/map.h to
not have to replicate the __is_transparent stuff. But I didn't found any
way to do such a thing.
2015-01-22 François Dumont
* include/bits/stl_tree.h (_Rb_tree<>::__is_transparent<>): Move to
outer
scope and
::unordered_map Key:int
Insertion: 1099 581 583 584 592 min=581 max=1099
Container:std::tr1::unordered_map Key:int
Insertion: 889 491 519 492 493 min=491 max=889
I prefer to propose it now because it impacts ABI.
2015-02-19 François Dumont
* include/bits/hashtable.h (_Hashtable
With patch.
On 18/02/2015 10:35, François Dumont wrote:
Hello
I am still studying hashtable performances and especially how to
reduce overhead compared to tr1 implementation. Most of the overhead
is coming from the additional modulo operations required with the new
data model. Having a
On 20/02/2015 14:22, Jonathan Wakely wrote:
On 18/02/15 10:35 +0100, François Dumont wrote:
Hello
I am still studying hashtable performances and especially how to
reduce overhead compared to tr1 implementation. Most of the overhead
is coming from the additional modulo operations required
Hi
Here is more or less the patch proposed on the ticket with the test
case also provided in the ticket.
2014-11-04 François Dumont
Jonathan Wakely
PR libstdc++/63698
* include/bits/stl_tree.h (_Reuse_or_alloc_node): Simplify constructor.
Always move to the left
/1.cc: Likewise.
* testsuite/25_algorithms/stable_sort/4.cc: New.
* testsuite/25_algorithms/inplace_merge/2.cc: New.
* testsuite/25_algorithms/stable_partition/2.cc: New.
Ok to commit ?
François
On 17/10/2014 22:46, François Dumont wrote:
Hi
As proposed in the bug report I just
o far better ?
If it is the whole usage of random numbers that you don't like I will
simply get rid of the new tests files.
François
On 10/11/2014 22:45, Jonathan Wakely wrote:
On 10/11/14 21:50 +0100, François Dumont wrote:
Any news about this one ?
Here is another version with additio
23:20, Jonathan Wakely wrote:
On 10/11/14 23:14 +0100, François Dumont wrote:
I introduced the random tests after Christopher Jefferson request
to have more intensive tests on those algos. Is it the whole stuff of
tests using random numbers that you don't like or just the usage of
mt19937 ?
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 te
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
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.
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
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:
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 to
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 it
>>'
@ 0x0x7fffdbf5edf0
}
iterator "__last" @ 0x0x7fffdbf5ea10 {
type =
std::move_iterator<__gnu_cxx::__normal_iteratorstd::default_delete >*, std::vectorstd::default_delete >> > > (mutable iterator);
state = past-the-end;
referen
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 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 comme
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 t
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ç
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 otherwis
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 co
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.
301 - 400 of 1037 matches
Mail list logo
