Maybe this last patch that has been out for a while.
Here it is again rebased as some symbols have been added since my last
proposal.
François
On 14/10/20 6:10 pm, François Dumont wrote:
After further testing this version was bugged because ld considered
that __create_backtrace
On 02/11/20 3:17 pm, Jonathan Wakely wrote:
On 01/11/20 20:48 +0100, François Dumont via Libstdc++ wrote:
Several tests are failing because of those missing symbols.
I understand why we need to export symbols relying in the versioned
namespace but I don't understand why we need to do it for
The gnu-versioned-namespace build is broken.
The fix in charconv/floating_from_chars.cc is quite trivial. I am not so
sure about the fix in sstream-inst.cc.
libstdc++: Fix gnu-version-namespace buid
libstdc++-v3/ChangeLog
* include/std/charconv (from_chars): Define only
On 30/10/20 2:37 pm, Jonathan Wakely wrote:
On 30/10/20 13:23 +, Jonathan Wakely wrote:
On 30/10/20 13:59 +0100, François Dumont via Libstdc++ wrote:
The gnu-versioned-namespace build is broken.
The fix in charconv/floating_from_chars.cc is quite trivial. I am
not so sure about the fix
+0100, François Dumont wrote:
On 30/10/20 2:37 pm, Jonathan Wakely wrote:
On 30/10/20 13:23 +, Jonathan Wakely wrote:
On 30/10/20 13:59 +0100, François Dumont via Libstdc++ wrote:
The gnu-versioned-namespace build is broken.
The fix in charconv/floating_from_chars.cc is quite trivial. I
Several tests are failing because of those missing symbols.
I understand why we need to export symbols relying in the versioned
namespace but I don't understand why we need to do it for _GLIBCXX_DEBUG
symbols which are not version namespace dependant.
Do you want to backport the Debug symbol
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
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
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 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.
I think I never got a clear answer that we'll wait for stage 1 to
consider this patch so here is a ping.
On 01/12/20 8:19 am, François Dumont wrote:
Let me know if I need to reference a specific paper or any other
Standard reference here. Maybe P1690R1 I used here ?
I tried to allow
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
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
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
On 01/02/21 6:43 pm, Jonathan Wakely wrote:
On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote:
After the debug issue has been fixed in PR 98466 the problem was not
in the debug iterator implementation itself but in the deque iterator
operator- implementation.
libstdc++: Make
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
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'll
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.
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 in uno
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 partial
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 partial
, __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
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 "0x%p", so resulting in something like: 0x0x012345678
Otherwise it is just enhancements, mostly avoiding
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
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 use
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:
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 partial
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
* testsuite/util/replacement_memory_operators.h
(counter::_M_increment): New.
(counter::_M_decrement): New.
(counter::reset()): New.
Tested under Linux x64.
Ok to commit ?
François
On 21/05/21 8:55 am, Jonathan Wakely wrote:
On Fri, 21 May 20
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
Hi
Here is the patch to add backtrace generation on _GLIBCXX_DEBUG
assertions thanks to libbacktrace.
In addition to this integration I am also improving the generation
of the assertion message thanks to the "%.*s" printf format, it avoids
an intermediate buffer most of the time. I
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 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,
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 idea of executing
On 01/02/21 8:09 pm, Jonathan Wakely wrote:
On 01/02/21 19:30 +0100, François Dumont via Libstdc++ wrote:
On 01/02/21 6:43 pm, Jonathan Wakely wrote:
On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote:
After the debug issue has been fixed in PR 98466 the problem was
not in the debug
libstdc++: Fix versioned namespace build
libstdc++-v3/ChangeLog:
* libsupc++/eh_ptr.cc (exception_ptr(__safe_bool)): Define if
_GLIBCXX_EH_PTR_COMPAT is defined.
(exception_ptr::_M_safe_bool_dummy()): Likewise.
At the moment some iterators like std::list<>::end() looks like
value-init iterators once detached.
I think using an iterator in such a state is wrong so here is a patch to
detect this.
This patch also add a new iterator state: singular (value-initialized)
Example of the output of the
After the debug issue has been fixed in PR 98466 the problem was not in
the debug iterator implementation itself but in the deque iterator
operator- implementation.
libstdc++: Make deque iterator operator- usable with value-init
iterators
N3644 implies that operator- can be used on
On 23/03/21 4:42 pm, Jonathan Wakely wrote:
On 20/03/21 22:32 +0100, François Dumont wrote:
Following your feedback here is the simplified version. I grouped it
with the patch I submitted before.
On 19/03/21 8:41 pm, Jonathan Wakely wrote:
I think we could just define on partial
I review the allocator aware move constructors of _GLIBCXX_DEBUG containers.
I think the recently added __gnu_debug basic_string one is also missing
the rvalue reference, no ?
libstdc++: _GLIBCXX_DEBUG Fix allocator aware move constructor
Fix several allocator aware move construtor
On 25/03/21 4:29 pm, Jonathan Wakely wrote:
On 25/03/21 14:48 +, Jonathan Wakely wrote:
On 25/03/21 13:05 +, Jonathan Wakely wrote:
On 24/03/21 22:48 +0100, François Dumont wrote:
I still need to find out why, when running test on
__gnu_debug::basic_string after the std::basic_string
On 27/03/21 10:07 pm, Jonathan Wakely wrote:
On 26/03/21 21:41 +0100, François Dumont via Libstdc++ wrote:
I review the allocator aware move constructors of _GLIBCXX_DEBUG
containers.
I think the recently added __gnu_debug basic_string one is also
missing the rvalue reference, no ?
You
On 25/03/21 4:29 pm, Jonathan Wakely wrote:
Oh, it's the same generate(sz) bug as you already found. But I've
found other bugs, e.g. with GLIBCXX_SEED_TEST_RNG=1908970375).
I think we should also add a check for non-empty containers to those
test functions, and ensure we don't try to erase from
n_advance(const
std::reverse_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const std::move_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* te
Following your feedback here is the simplified version. I grouped it
with the patch I submitted before.
On 19/03/21 8:41 pm, Jonathan Wakely wrote:
On 16/03/21 21:55 +0100, François Dumont via Libstdc++ wrote:
Following:
https://gcc.gnu.org/pipermail/libstdc++/2021-March/052158.html
Here
Following:
https://gcc.gnu.org/pipermail/libstdc++/2021-March/052158.html
Here is the patch to complete __gnu_debug::basic_string support.
Contrarily to what I thought code in std::basic_string to generate a
basic_string_view works just fine for __gnu_debug::basic_string.
libstdc++:
Here is the patch to correctly deal with the new __dp_sign_max_size.
I prefer to introduce new __can_advance overloads for this to correctly
deal with the _Distance_precision in it. _M_valid_range was also
ignoring __dp_sign_max_size.
libstdc++: [_GLIBCXX_DEBUG] Fix management of
__gnu_debug::basic_string is not extensively used nor extensively tested
so not actively maintained.
So here is a first patch to fix some problems and increase test
coverage. I plan another patch cause I think it is missing some C++17
methods.
Tested under Linux x86_64, ok to commit ?
Hi
Ok to backport this to gcc-10 branch ?
Tested under Linux x86_64.
François
On 13/04/21 10:51 pm, redi at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
Jonathan Wakely changed:
What|Removed |Added
On 08/04/21 3:07 pm, Jonathan Wakely wrote:
On 11/03/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I eventually prefer to propose this version.
Compared to the previous one I have the _M_can_advance calling the
former one with correct number of elements to check for advance
test run under Linux x86_64.
Ok to commit if all tests pass ?
François
On 03/02/21 12:24 pm, Jonathan Wakely wrote:
On 03/02/21 11:23 +, Jonathan Wakely wrote:
On 25/01/21 19:21 +0100, François Dumont via Libstdc++ wrote:
I think I never got a clear answer that we'll wait for stage 1 to
con
Any feedback ?
Thanks
On 08/08/21 9:34 pm, François Dumont wrote:
After further testing here a fixed version which imply less changes.
Moreover I already commit the fixes unrelated with this patch.
libstdc++: [_GLIBCXX_ASSERTIONS] Activate basic debug checks
libstdc++-v3/ChangeLog
Since std::allocator is not specialized anymore in
_GLIBCXX_INLINE_VERSION mode _ExtPtr_allocator specialization do
not compile
because std::allocator is incomplete.
So I think primary _ExtPtr_allocator template should also be prefered in
_GLIBCXX_INLINE_VERSION mode.
Ok to commit ?
On 17/07/20 2:58 pm, Jonathan Wakely wrote:
On 17/11/19 22:31 +0100, François Dumont wrote:
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
On 09/08/21 12:45 pm, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++
wrote:
Some newly introduced tests in
23_containers/unordered_map/cons/default.cc
Some newly introduced tests in
23_containers/unordered_map/cons/default.cc revealed that we are forcing
the allocator type to have a operator==.
It can be avoided by checking allocator_traits::is_always_equal.
libstdc++: [_GLIBCXX_DEBUG] Avoid allocator operator== when always
equal
On 09/08/21 1:52 pm, François Dumont wrote:
On 09/08/21 12:45 pm, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote:
On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++
wrote:
Some newly introduced tests
This is a trivial fix following a recent change on __glibcxx_assert.
libstdc++: Fix dg-prune-output assertion message
Since __glibcxx_assert changes in r6b42b5a the generated assertion
message
has changed.
libstdc++-v3/ChangeLog:
*
checks when _GLIBCXX_ASSERTIONS
is defined.
Ok to commit ?
François
On 06/08/21 4:52 pm, François Dumont wrote:
On 07/06/21 6:25 am, François Dumont wrote:
On 03/06/21 2:31 pm, Jonathan Wakely wrote:
+ }
+
/* Checks that [first, last) is a valid range, and then returns
On 07/06/21 6:25 am, François Dumont wrote:
On 03/06/21 2:31 pm, Jonathan Wakely wrote:
+ }
+
/* Checks that [first, last) is a valid range, and then returns
* __first. This routine is useful when we can't use a separate
* assertion statement because, e.g., we are in a constructor
Hi
Sorry for the delay, I had just miss this message.
I think you are clearly more expert than me for the changes you
propose. I had a look at the patch and it seems just fine as it keeps
the forwarding as expected. Nice simplification in
_NodeBuilder<_Select1st>, we indeed only need
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 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
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
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
. 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_DEBUG
On 27/09/21 11:06 pm, Jonathan Wakely wrote:
On Mon, 27 Sept 2021 at 21:26, François Dumont via Libstdc++
wrote:
Here is a small patch to fix a test which fails in
_GLIBCXX_VERSION_NAMESPACE mode.
IMHO it would be better to avoid putting content in
versioned namespace, no ?
No opinion
Here is the _Safe_iterator one.
Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.
For _Safe_iterator maybe I should specialize only when instantiated with
__normal_iterator ? Or maybe limit to random_access_iterator_tag ?
Whatever the
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
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
: 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 I noticed
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
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
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
Here is a small patch to fix a test which fails in
_GLIBCXX_VERSION_NAMESPACE mode.
IMHO it would be better to avoid putting content in
versioned namespace, no ?
There is of course more work to do, so for now here is the simpler approach.
Ok to commit ?
François
diff --git
Ping ?
On 16/08/21 9:03 pm, François Dumont wrote:
On 17/07/20 2:58 pm, Jonathan Wakely wrote:
On 17/11/19 22:31 +0100, François Dumont wrote:
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
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 wh
Hi
Is there a chance for this patch to be integrated for next gcc
release ?
François
On 23/09/21 6:36 am, François Dumont wrote:
Ping ?
On 16/08/21 9:03 pm, François Dumont wrote:
On 17/07/20 2:58 pm, Jonathan Wakely wrote:
On 17/11/19 22:31 +0100, François Dumont wrote
On 23/12/21 2:03 pm, Jonathan Wakely wrote:
On 21/12/21 07:07 +0100, François Dumont wrote:
Hi
??? Is there a chance for this patch to be integrated for next gcc
release ?
Yes, I think this can still make it for GCC 12 (the patch was first
posted long ago in stage 1 and it's just me being
On 21/12/21 7:28 am, Daniel Krügler wrote:
Am Di., 21. Dez. 2021 um 07:08 Uhr schrieb François Dumont via
Libstdc++ :
Hi
Is there a chance for this patch to be integrated for next gcc
release ?
François
No counterargument for the acceptance, but: Shouldn't
__small_size_threshold
I tried to use the same approach I used for node based containers but
got ambiguity on erase calls. I think this simple version will do the work.
libstdc++: [_GLIBCXX_DEBUG] Enhance std::erase_if for vector/deque
libstdc++-v3/ChangeLog:
* include/std/deque (erase_if): Use
like std::rotate in 9.1
I'll try to finish the review tomorrow.
J.
On 27/05/21 07:04 +0200, François Dumont via Libstdc++ wrote:
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
Hi
Here is a proposal to limit performance impact of _GLIBCXX_DEBUG
mode on __erase_nodes_if.
As you can see I am adding erase overloads on the Debug container
to accept base iterators. So it exposes an additional non-Standard
method, do you think it is any issue.
Note that
I can't see any clue on how my commit can have had an impact on below code.
I don't think libstdc++ hash table has any relation with gcc hash table.
Still, I'm rebuilding gcc at my revision to confirm.
On 10/11/21 1:05 am, H.J. Lu wrote:
On Mon, Nov 8, 2021 at 1:37 PM François Dumont via Gcc
On 09/11/21 5:25 pm, Jonathan Wakely wrote:
On Mon, 8 Nov 2021 at 21:36, François Dumont <mailto:frs.dum...@gmail.com>> wrote:
Yet another version this time with only 1 guard implementation.
The predicate to invalidate the safe iterators has been externalized.
Ok to com
On 11/11/21 9:41 pm, Jonathan Wakely wrote:
On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely <mailto:jwak...@redhat.com>> wrote:
On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely mailto:jwak...@redhat.com>> wrote:
On Mon, 8 Nov 2021 at 21:36, François Dumont
libstdc++: [_GLIBCXX_DEBUG] Remove _Safe_container<>::_M_safe()
Container code cleanup to get rid of _Safe_container<>::_M_safe()
and just
_Safe:: calls which use normal inheritance. Also remove several
usages of _M_base()
which can be most of the time ommitted and sometimes
libstdc++: Unordered containers merge re-use hash code.
When merging between 2 unordered containers with same hasher we can
re-use
the cached hash code if any.
Use previous insert iterator as a hint for the next insert in case
of multi container.
*
libstdc++: In _Hashtable, use insertion hint as much as possible.
Make use in unordered containers of the user provided hint iterator
as much as possible.
Hint is now used:
- As a hint for allocation, in order to limit memory fragmentation when
allocator is making use of
On 15/11/21 12:25 am, Jonathan Wakely wrote:
On Sun, 14 Nov 2021 at 13:31, François Dumont via Libstdc++
wrote:
libstdc++: Unordered containers merge re-use hash code.
When merging between 2 unordered containers with same hasher we can
re-use
the cached hash code if any
/debug/merge1_neg.cc: New test.
*
testsuite/23_containers/unordered_set/debug/merge2_neg.cc: New test.
*
testsuite/23_containers/unordered_set/debug/merge3_neg.cc: New test.
*
testsuite/23_containers/unordered_set/debug/merge4_neg.cc: New test.
* te
Yet another version this time with only 1 guard implementation. The
predicate to invalidate the safe iterators has been externalized.
Ok to commit ?
On 06/11/21 2:51 pm, François Dumont wrote:
You were right to delay your reply. Here is a new version with less
code duplication and a bug fix
the _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
Hi
Any conclusion regarding this thread ?
François
On 06/10/21 7:25 pm, François Dumont wrote:
I forgot to ask if with this patch this overload:
template
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gn
2:12 pm, Jonathan Wakely wrote:
On Tue, 14 Dec 2021 at 06:53, François Dumont wrote:
Hi
Any conclusion regarding this thread ?
François
On 06/10/21 7:25 pm, François Dumont wrote:
> I forgot to ask if with this patch this overload:
>
> template
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
We have a regression regarding management of types convertible to
value_type. It is an occurrence of PR 56112 but for the insert method.
libstdc++: [_Hashtable] Insert range of types convertible to
value_type PR 56112
Fix insertion of range of types convertible to value_type.
On 21/02/22 21:54, Jonathan Wakely wrote:
On Mon, 21 Feb 2022 at 18:00, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
Gentle reminder, it is important to have this for gcc 12.
Well, it's been broken since 4.8, so another year wouldn't be the end
of the
Gentle reminder, it is important to have this for gcc 12.
On 15/02/22 10:05, François Dumont wrote:
We have a regression regarding management of types convertible to
value_type. It is an occurrence of PR 56112 but for the insert method.
libstdc++: [_Hashtable] Insert range of types
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
801 - 900 of 1024 matches
Mail list logo
