On 20/05/21 6:44 pm, Jonathan Wakely wrote:
On 06/05/21 22:03 +0200, François Dumont via Libstdc++ wrote:
Hi
Considering your feedback on backtrace in debug mode is going to
take me some time so here is another one.
Compared to latest submission I've added a _Hash_arg_t pa
On 25/05/21 11:58 am, Jonathan Wakely wrote:
On 22/05/21 22:08 +0200, François Dumont via Libstdc++ wrote:
Here is the part of the libbacktrace patch with the enhancement to
the rendering of assert message.
It only contains one real fix, the rendering of address. In 2 places
it was done with
Following latest fixes in std::inplace_merge and std::stable_sort you
propose Jonathan to enhance branching in the first.
Here is a proposal based on yours to do so in both algos.
libstdc++: Enhance branching in std::inplace_merge and std::stable_sort
libstdc++-v3/ChangeLog:
We have been talking for a long time of a debug mode with less impact on
performances.
I propose to simply use the existing _GLIBCXX_ASSERTIONS macro.
libstdc++: [_GLIBCXX_ASSERTIONS] Activate basic debug checks
Use _GLIBCXX_ASSERTIONS as a _GLIBCXX_DEBUG light mode. When
defined it a
, __check_partitioned_lower,
__check_partitioned_upper): Use latter.
Ok to commit ?
François
On 27/05/21 7:37 pm, François Dumont wrote:
We have been talking for a long time of a debug mode with less impact
on performances.
I propose to simply use the existing _GLIBCXX_ASSERTIONS macro
On 01/06/21 8:10 pm, Jonathan Wakely wrote:
On 01/06/21 18:47 +0100, Jonathan Wakely wrote:
On 01/06/21 18:45 +0100, Jonathan Wakely wrote:
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git
a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite
On 03/06/21 2:31 pm, Jonathan Wakely wrote:
On 27/05/21 19:37 +0200, François Dumont via Libstdc++ wrote:
We have been talking for a long time of a debug mode with less impact
on performances.
We already have it, that's what _GLIBCXX_ASSERTIONS already is :-)
I propose to simply us
I would like to renew this proposal.
I considered all your feedbacks expect:
On 02/11/20 3:11 pm, Jonathan Wakely wrote:
There's no point doing it if you still use raw pointers.
It either has to be done completely, or it's a waste of time and
energy.
Why ? Can you provide the Standard docu
On 02/10/21 12:29 am, Jonathan Wakely wrote:
On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
wrote:
Here is the _Safe_iterator one.
Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.
Oops, thanks!
For _Safe_iterator maybe I
fault: return {
std::addressof(__e) }; otherwise. This way we wouldn't have to provide a
pointer_to method on __normal_iterator.
François
On 02/10/21 12:29 am, Jonathan Wakely wrote:
On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
wrote:
Here is the _Safe_iterator one.
Doing so
On 02/10/21 10:24 pm, Jonathan Wakely wrote:
On Sat, 2 Oct 2021 at 18:27, François Dumont wrote:
I would like to propose this alternative approach.
In this patch I make __normal_iterator and random iterator
_Safe_iterator compatible for pointer_traits primary template.
Regarding
On 04/10/21 10:05 pm, François Dumont wrote:
On 02/10/21 10:24 pm, Jonathan Wakely wrote:
On Sat, 2 Oct 2021 at 18:27, François Dumont wrote:
I would like to propose this alternative approach.
In this patch I make __normal_iterator and random iterator
_Safe_iterator compatible for
to validate both __gnu_cxx::__normal_iterator<>
__to_address overload in normal mode and the
Tested under Linux x86_64.
Ok to commit ?
François
On 04/10/21 10:30 pm, Jonathan Wakely wrote:
On Mon, 4 Oct 2021 at 21:28, François Dumont via Libstdc++
wrote:
On 04/10/21 10:05 p
se
return std::__to_address(__ptr.operator->());
}
should be removed ?
Or perhaps just the _Safe_iterator_base branch in it ?
On 06/10/21 7:18 pm, François Dumont wrote:
Here is another proposal with the __to_address overload.
I preferred to let it open to any kind of __normal_iterato
Hi
libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
The _GLIBCXX_DEBUG unordered containers need a dedicated merge
implementation
so that any existing iterator on the transfered nodes is properly
invalidated.
Add typedef/using declaration for everything used as
Hi
On a related subject I am waiting for some feedback on:
https://gcc.gnu.org/pipermail/libstdc++/2021-August/053005.html
On 11/10/21 6:49 pm, Jonathan Wakely wrote:
This enables lightweight checks for the __glibcxx_requires_valid_range
and __glibcxx_requires_string_len macros when _GLI
On 14/10/21 7:43 pm, Jonathan Wakely wrote:
On Thu, 14 Oct 2021 at 18:11, François Dumont wrote:
Hi
On a related subject I am waiting for some feedback on:
https://gcc.gnu.org/pipermail/libstdc++/2021-August/053005.html
I'm concerned that this adds too much overhead fo
. Maybe I'll be able to make use of it in Debug
implementation too.
François
On 14/10/21 10:23 am, Jonathan Wakely wrote:
On Wed, 13 Oct 2021 at 18:10, François Dumont via Libstdc++
wrote:
Hi
libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
The _GLIBCXX_
it is what is
expected by the extract.
Tested under Linux x86_64.
Ok to commit ?
François
On 16/10/21 4:52 pm, Jonathan Wakely wrote:
On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++,
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
Hi
Here is the new proposal. M
On 21/10/21 6:55 pm, Jonathan Wakely wrote:
On Thu, 21 Oct 2021 at 17:52, François Dumont <mailto:frs.dum...@gmail.com>> wrote:
I eventually would like to propose a different approach.
I am adding a hook in normal implementation to let the
_GLIBCXX_DEBUG code know when
_GLIBCXX_DEBUG mode won't try to
invalidate anything because the source size won't have changed.
Ok to commit ?
François
On 16/10/21 4:52 pm, Jonathan Wakely wrote:
On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++,
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
Hi
On 15/07/21 5:26 pm, Jonathan Wakely via Libstdc++ wrote:
This results in slightly smaller code when assertions are enabled when
either using Clang (because it adds code to call std::terminate when
potentially-throwing functions are called in a noexcept function) or a
freestanding or non-verbose
Is it too early to consider this patch ? Or just lack of time ?
Considering the patch I would really appreciate that, if validated, it
gets in as early as possible in next release.
Thanks,
François
On 24/04/21 3:46 pm, François Dumont wrote:
Hi
Here is the patch to add backtrace
On 03/05/21 11:06 pm, Jonathan Wakely wrote:
On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:
Is it too early to consider this patch ? Or just lack of time ?
I haven't had time to review it yet, but my general feeling hasn't
changed. I still don't like the id
On 04/05/21 4:52 am, Alexandre Oliva wrote:
This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally. It was tested with
various vx7r2 targets. Ok to install?
From: Corentin Gay
+
+// Copyright (C) 2001-2021 Free Software Foundation, In
On 05/05/21 2:01 pm, Jonathan Wakely via Libstdc++ wrote:
Passing plain char to isdigit is undefined if the value is negative.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum): Pass unsigned
char to std::isdigit.
Tested powerpc64le-linux. Committed to trunk.
ally remove its nested argument_type it
will be. I also wonder if it is not easier to handle for the compiler,
not sure about that thought.
Tested under Linux x86_64, ok to commit ?
François
On 04/12/20 10:10 am, François Dumont wrote:
Following submission of the heterogeneous lookup i
On 07/05/21 4:26 pm, Jonathan Wakely wrote:
On 05/05/21 12:33 +0100, Jonathan Wakely wrote:
On 24/04/21 15:46 +0200, François Dumont via Libstdc++ wrote:
Hi
Here is the patch to add backtrace generation on _GLIBCXX_DEBUG
assertions thanks to libbacktrace.
Ville pointed out that we&#x
Hi
No chance yet to review this proposal ?
François
On 06/05/21 10:03 pm, François Dumont wrote:
Hi
Considering your feedback on backtrace in debug mode is going to
take me some time so here is another one.
Compared to latest submission I've added a _Hash_arg_t pa
Still no chance to review ?
On 14/11/22 18:56, François Dumont wrote:
Gentle reminder.
Sorry if I should have committed it as trivial but I cannot do it
anymore now that I asked :-)
On 12/10/22 22:18, François Dumont wrote:
libstdc++: Remove _Alloc_node instance in _Rb_tree [PR107189
Thanks for fixing this.
Here is the extension of the fix to all post-increment/decrement
operators we have on _GLIBCXX_DEBUG iterator.
I prefer to restore somehow previous implementation to continue to have
_GLIBCXX_DEBUG post operators implemented in terms of normal post operators.
I also
:
return { __cur, this->_M_sequence };
than in the _Safe_iterator:
return _Safe_iterator(__cur, this->_M_sequence);
In the case where the user code do not use it ?
Fully tested now, ok to commit ?
François
On 11/01/23 07:03, François Dumont wrote:
Thanks for fixing this.
Here is the ext
On 12/01/23 13:00, Jonathan Wakely wrote:
On Thu, 12 Jan 2023 at 05:52, François Dumont wrote:
Small update for an obvious compilation issue and to review new test
case that could have lead to an infinite loop if the increment issue was
not detected.
I also forgot to ask if there is more
Committed with the idiomatic approach.
I'll work on this additional check later.
On 12/01/23 22:35, Jonathan Wakely wrote:
On Thu, 12 Jan 2023 at 18:25, François Dumont wrote:
On 12/01/23 13:00, Jonathan Wakely wrote:
On Thu, 12 Jan 2023 at 05:52, François Dumont wrote:
Small update f
On 13/01/23 17:33, Jonathan Wakely wrote:
On Mon, 5 Dec 2022 at 21:14, François Dumont via Libstdc++
wrote:
I just rebased this patch.
All good apart from the to_chars/from_chars symbols issue.
François
On 11/10/22 19:28, François Dumont wrote:
Hi
Now that pretty printer is fixed
On 13/01/23 18:06, Jonathan Wakely wrote:
On Fri, 13 Jan 2023 at 16:33, Jonathan Wakely wrote:
On Mon, 5 Dec 2022 at 21:14, François Dumont via Libstdc++
wrote:
I just rebased this patch.
All good apart from the to_chars/from_chars symbols issue.
François
On 11/10/22 19:28, François
On 13/01/23 18:15, Jonathan Wakely wrote:
@@ -396,7 +376,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Non-inline namespace for components replaced by alternates in active
mode.
namespace __cxx1998
{
-# if _GLIBCXX_USE_CXX11_ABI
+# if _GLIBCXX_USE_CXX11_ABI && ! _GLIBCXX_VERSION_NAMESPACE
On 21/08/2023 23:26, Jonathan Wakely wrote:
On Mon, 21 Aug 2023 at 21:20, François Dumont wrote:
Here is the updated and tested patch.
OK for trunk, thanks.
We could consider it for the branches too (I'm going to remove the
global strings on the gcc-13 branch tomorrow).
It's
Hi
The few tests that are failing in versioned namespace mode are due to
those friend declarations.
This is a fix proposal even if I considered 2 other options:
1. Make __format::_Arg_store a struct and so do not bother with friend
declarations.
2. Consider it as a compiler bug and do noth
François
On 17/08/2023 19:17, François Dumont wrote:
Another fix to define __cow_string(const std::string&) in
cxx11-stdexcept.cc even if ! _GLIBCXX_USE_DUAL_ABI.
On 13/08/2023 21:51, François Dumont wrote:
Here is another version with enhanced sizeof/alignof static_assert in
string-
Hi
Any feedback regarding this patch ?
François
On 24/07/2023 13:02, François Dumont wrote:
libstdc++: [_Hashtable] Make more use of insertion hint
When inserting an element into an empty bucket we currently insert
the new node
after the before-begin node so in first position. The
On 01/09/2023 10:59, Jonathan Wakely wrote:
On Tue, 29 Aug 2023 at 20:52, François Dumont via Libstdc++
wrote:
Hi
Any feedback regarding this patch ?
This is a fairly large patch
I've decided to split it, at least in 2.
So just ignore this one, I'll submit new ones once ab
Hi
Any news regarding this problem ?
François
On 23/08/2023 19:35, François Dumont wrote:
Hi
The few tests that are failing in versioned namespace mode are due to
those friend declarations.
This is a fix proposal even if I considered 2 other options:
1. Make __format::_Arg_store a struct
Following confirmation of the fix by TC here is the patch where I'm
simply adding a 'constexpr' on _M_next().
Please let me know this ChangeLog entry is correct. I would prefer this
patch to be assigned to 'TC' with me as co-author but I don't know how
to do such a thing. Unless I need to chan
On 11/09/2023 13:51, Jonathan Wakely wrote:
On Sun, 10 Sept 2023 at 14:57, François Dumont via Libstdc++
wrote:
Following confirmation of the fix by TC here is the patch where I'm
simply adding a 'constexpr' on _M_next().
Please let me know this ChangeLog entry is correct.
It's working and what's I've committed.
Thanks
On 12/09/2023 19:04, Jonathan Wakely wrote:
On Tue, 12 Sept 2023 at 17:47, Jonathan Wakely wrote:
On Wed, 23 Aug 2023 at 18:35, François Dumont via Libstdc++
wrote:
Hi
The few tests that are failing in versioned namespace
Committed as trivial.
libstdc++: Limit synopsis test to normal namespace
libstdc++-v3/ChangeLog
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Add
{ dg-require-normal-namespace "" }.
François
diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/syn
?
On 12/09/2023 18:09, Jonathan Wakely wrote:
On Mon, 11 Sept 2023 at 18:19, François Dumont wrote:
On 11/09/2023 13:51, Jonathan Wakely wrote:
On Sun, 10 Sept 2023 at 14:57, François Dumont via Libstdc++
wrote:
Following confirmation of the fix by TC here is the patch where I'm
simply ad
libstdc++: [_Hashtable] Avoid redundant usage of rehash policy
Bypass usage of __detail::__distance_fwd and check for need to rehash
when assigning an initializer_list to
an unordered_multimap or unordered_multiset.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h
(_Insert_ba
s also with those options.
If you prefer we can go without it and let Valgrind detect the issue.
Whatever, once the patch is in place it doesn't fail anymore.
François
On 27/12/19 11:57 am, François Dumont wrote:
Here is the patch to extend DR 526 to forward_list and list remove_if
and un
Hi
Here is the new proposal.
As we can't remove template parameters I simply restore those that
I tried to pass differently _H2 and _ExtractKey, so eventually I only
remove usage of _Hash which I renamed in _Unused. Maybe I can keep the
doc about it in hashtable.h and just add a remar
Deeply sorry, I indeed didn't sent the patch I wanted to commit. It was
in 3 commits on my side and it looks like I had miss the last one
regarding the changes for _ExtractKey.
But moreover I had change the ebo helper index wrongly, I missed the abi
change here, thanks for fixing it.
On 26/
Hi
No chance to review this small patch ?
François
On 30/06/20 10:33 pm, François Dumont wrote:
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
When I commit the small series of patches on _Hashtable I realize that I
miss a part on the one regarding reservation management on range
insertion. I've added a comment saying that we consider that all
initializer_list elements will be inserted.
For the moment it is true only for assignement
On 01/09/20 3:25 pm, Jonathan Wakely wrote:
On 01/09/20 14:06 +0200, François Dumont wrote:
Hi
No chance to review this small patch ?
I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.
I shouldn't have
libstdc++: Use only public basic_streambuf methods in __copy_move_a2
overload
__copy_move_a2 for istreambuf_iterator can be implemented using public
basic_streambuf in_avail and sgetn so that __copy_move_a2 do not need to be
basic_streambuf friend.
libstdc++-v3/ChangeLog:
* include/std
libstdc++: Use only public basic_streambuf methods in std::advance overload
std::advance overload for istreambuf_iterator can be implemented using
basic_streambuf public pubseekoff method so that it doesn't have to be
basic_streambuf friend.
libstdc++-v3/ChangeLog:
* include/std/streamb
libstdc++: Add std::advance overload for ostreambuf_iterator
Implement std::advance overload for ostreambuf_iterator using
basic_streambuf
pubseekof.
libstdc++-v3/ChangeLog:
* include/bits/streambuf_iterator.h (ostreambuf_iterator): Add
std::advance friend declaration.
On 10/09/20 5:05 pm, Jonathan Wakely wrote:
On 09/09/20 22:11 +0200, François Dumont via Libstdc++ wrote:
libstdc++: Use only public basic_streambuf methods in __copy_move_a2
overload
__copy_move_a2 for istreambuf_iterator can be implemented using public
basic_streambuf in_avail and sgetn so
On 10/09/20 5:19 pm, Jonathan Wakely wrote:
On 09/09/20 22:12 +0200, François Dumont via Libstdc++ wrote:
libstdc++: Add std::advance overload for ostreambuf_iterator
Implement std::advance overload for ostreambuf_iterator using
basic_streambuf
pubseekof.
libstdc++-v3/ChangeLog:
    Â
I wonder if this fix is correct because if it is you spent more time
making ext_ptr.cc works than fixing it :-)
libstdc++ Hashtable: Fix node manipulation when using custom pointer
Use std::__to_address to get NodeHandle when reinserting nodes.
* include/bits/hashtable.h
I eventually committed the attached patch which consider all your
remarks and moreover put back the move constructor implementation where
it used to be (not inline). It limits the size of the patch.
I also added comments on true_type/false_type new usages like you
advised on [Hashtable 0/6] th
On 17/07/20 12:11 pm, Jonathan Wakely wrote:
N.B. the 0/6 entry of a patch series is supposed to be a cover letter
describing the changes in the series, not one of the patches.
If you have patches 0/6, 1/6, 2/6 ... 6/6 then you actually have seven
patches, not six!
Anyway ...
On 19/12/19 20:17
On 17/07/20 12:36 pm, Jonathan Wakely wrote:
On 16/12/19 08:18 +0100, François Dumont wrote:
A small refresh on this patch now tested also for versioned namespace
which require printers.py to be updated.
Note that this simplification works also for normal mode so I can
apply it independently
On 17/07/20 1:35 pm, Jonathan Wakely wrote:
On 19/12/19 20:22 +0100, François Dumont wrote:
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree
I wonder if following the application of this patch we shouldn't bump
versioned namespace through _GLIBCXX_BEGIN_NAMESPACE_VERSION ?
Unless it is still considered as experimental.
François
On 31/07/20 11:03 pm, François Dumont wrote:
On 17/07/20 12:36 pm, Jonathan Wakely wrote:
On 16/
Hi
I am not clear about current stage so I am proposing this trivial patch
to find out if we are back in stage 1.
This patch extend the overload so that it is used even when
_GLIBCXX_DEBUG mode is activated.
* include/bits/stl_algobase.h (struct _Bit_iterator): New
declaration.
This patch purpose is to make sure that existing
std::copy/std::copy_n overloads for char* will also be used for
std::deque iterators when dealing with istreambuf_iterator. It
also make sure that it still works when _GLIBCXX_DEBUG is activated.
* include/bits/stl_algo.h (__copy_n_a): M
I just committed this patch.
François
On 03/03/20 10:11 pm, François Dumont wrote:
After the fix of PR 91910 I tried to consider other possible race
condition and I think we still have a problem.
Like stated in the PR when a container is destroyed all associated
iterators are made singular
On 11/05/20 12:51 pm, Ville Voutilainen wrote:
On Mon, 11 May 2020 at 00:09, François Dumont via Libstdc++
wrote:
I just committed this patch.
This was a commit-without-review. When the patch was originally
posted, the maintainer said
"Let's revisit it in a few weeks.". That&#x
Now fully tested, ok to commit ?
On 07/05/20 9:12 am, François Dumont wrote:
This patch purpose is to make sure that existing
std::copy/std::copy_n overloads for char* will also be used for
std::deque iterators when dealing with istreambuf_iterator. It
also make sure that it still works
clude/debug/unordered_map: Adapt.
* include/debug/unordered_set: Adapt.
* testsuite/23_containers/unordered_map/allocator/ext_ptr.cc: New.
*
testsuite/23_containers/unordered_multimap/allocator/ext_ptr.cc: New.
*
testsuite/23_containers/unordered_multiset/allocat
No chance to review this ?
On 07/05/20 9:12 am, François Dumont wrote:
This patch purpose is to make sure that existing
std::copy/std::copy_n overloads for char* will also be used for
std::deque iterators when dealing with istreambuf_iterator. It
also make sure that it still works when
On 21/05/20 2:17 pm, Jonathan Wakely wrote:
Why is the optimization not done for C++03 mode?
I did it this way because the new std::copy overload rely on std::copy_n
implementation details which is a C++11 algo.
It looks like the uses of 'auto' can be reaplced easily, and
__enable_if_t<> c
On 22/05/20 10:57 pm, François Dumont wrote:
On 21/05/20 2:17 pm, Jonathan Wakely wrote:
Why is the optimization not done for C++03 mode?
I did it this way because the new std::copy overload rely on
std::copy_n implementation details which is a C++11 algo.
It looks like the uses of '
Now tested in C++98 mode, there was indeed a small problem.
I even wonder if I shouldn't have extend the std::copy overload to any
call with deque iterator as the output so that it is transform into an
output to pointer.
Ok to commit ?
François
On 23/05/20 6:37 pm, Jonathan Wakely wrote:
O
On 24/05/20 3:43 pm, François Dumont wrote:
Now tested in C++98 mode, there was indeed a small problem.
I even wonder if I shouldn't have extend the std::copy overload to any
call with deque iterator as the output so that it is transform into an
output to pointer.
Ignore this remark,
I added a try_emplace at the underlying _Hashtable level which I use in
both insert_or_assign and try_emplace.
I am not making any use of the hint for the moment. I'll review this
once my other hashtable patches are being validated.
PR libstdc++/95079
* include/bits/ha
Hi
Any feedback regarding this patch ?
François
On 26/05/20 1:45 pm, François Dumont wrote:
On 24/05/20 3:43 pm, François Dumont wrote:
Now tested in C++98 mode, there was indeed a small problem.
I even wonder if I shouldn't have extend the std::copy overload to
any call with
Hi
I'd like to commit this small fix to complete _GLIBCXX_DEBUG constexpr
compatibility. There are still 2 macros not using __glibcxx_assert_1.
It fixes the generated diagnostic to have the __failed_assertion rather
than a message saying that _Error_formatter::_M_error is not constexpr.
Some tests are XPASS because array assertions have been disabled for a
good reason in C++11.
I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks
shouldn't target C++14 too. At the moment they are failing as expected
but because of an Undefined Behavior no ?
The other test is f
On 13/12/20 11:17 pm, Jonathan Wakely wrote:
On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote:
Some tests are XPASS because array assertions have been disabled for
a good reason in C++11.
I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks
shouldn't target C++14 to
On 14/12/20 11:08 am, Jonathan Wakely wrote:
On Mon, 14 Dec 2020, 06:51 François Dumont via Libstdc++,
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
On 13/12/20 11:17 pm, Jonathan Wakely wrote:
> On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote:
>> Some
On 22/12/20 10:12 pm, Alexandre Oliva wrote:
Some tests uses structures from the libstdc++ that are present only if
the target has a wchar.h header. However, those tests do not check
that the target supports those constructs before executing the tests.
Looks like those tests should be in some
On 22/12/20 10:12 pm, Alexandre Oliva wrote:
Some tests uses structures from the libstdc++ that are present only if
the target has a wchar.h header. However, those tests do not check
that the target supports those constructs before executing the tests.
Like you already spotted in another threa
On 22/12/20 10:27 pm, Alexandre Oliva wrote:
This change extracts apart the wchar specific parts of character
conversion tests to allow conditonalizating these parts on actual
wchar support while applying the rest more generally.
This turned out useful during our work on the libstdc++ support
fo
I think the PR is not limited to unordered containers iterator, it
impacts all _GLIBCXX_DEBUG iterators.
However unordered containers local_iterator was more complicated to
handle. Because of c++/65816 I prefer to review _Node_iterator_default
constructor to set _M_cur to nullptr even if in pr
Hi
I had another look to this attempt to properly support alloc fancy
pointers.
I consider all your remarks appart from the big one below about all
this being a waste of time :-)
I do not see why we should use the alloc fancy pointer type in our
_Hashtable implementation detail
On 14/01/21 6:10 pm, Jonathan Wakely wrote:
On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it
impacts all _GLIBCXX_DEBUG iterators.
However unordered containers local_iterator was more complicated to
handle. Becau
On 14/01/21 6:15 pm, Jonathan Wakely wrote:
On 14/01/21 17:10 +, Jonathan Wakely wrote:
On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it
impacts all _GLIBCXX_DEBUG iterators.
However unordered containers loca
Hi
Here is the last of my algo patches this time to extend the memcmp
optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
To do so I had to return int in implementation details of
lexicographical_compare to make sure we can treat a deque iterator range
by chunk in a perform
On 08/06/20 8:20 pm, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
   To do so I had to return int in impleme
On 09/06/20 12:24 pm, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo pat
On 09/06/20 10:53 pm, Jonathan Wakely wrote:
On 09/06/20 22:42 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrot
On 10/06/20 4:49 pm, Jonathan Wakely wrote:
On 10/06/20 08:18 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 10:53 pm, Jonathan Wakely wrote:
This reminds me that I was going to extend the condition for using
memcmp to also apply to unsigned integers with sizeof(T) > 1 on big
endian t
nux x86_64.
Commit message:
libstdc++: Limit memory allocation in stable_sort/inplace_merge (PR
83938)
Reduce memory consumption in stable_sort/inplace_merge to what is used.
Co-authored-by: François Dumont
libstdc++-v3/ChangeLog:
2020-06-11 John Chang
Franç
Gentle remider.
On 11/06/20 8:32 am, François Dumont wrote:
As we are on patching algos we still have this old one.
From the original patch I only kept the memory optimization part
as the new performance test was not showing good result for the other
part to change pivot value. I also
On 24/06/20 7:39 pm, Jonathan Wakely wrote:
On 11/06/20 08:32 +0200, François Dumont via Libstdc++ wrote:
As we are on patching algos we still have this old one.
   From the original patch I only kept the memory optimization
part as the new performance test was not showing good result for
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can
attack from front and back. But
901 - 1000 of 1064 matches
Mail list logo
