Sorry to react so late on this patch.
I'm only surprised by the expected result of the added __builtin_expect
which is 0.
It means that we consider that hasher is not perfect, we have several
entries in the same bucket. Shouldn't we reward those that are spending
time on their hasher to make it a
Hi
As proposed on another thread here is the patch to make std::__addressof
and std::addressof compile time equivalent.
Maybe not entirely because of the [[__nodiscard__]] on std::addressof
but still closer.
libstdc++: Have std::addressof use __builtin_addressof
Rather than calling
Hi
Here is an update with the alloc ptr specific tests and so fixes.
PR updated:
https://forge.sourceware.org/gcc/gcc-TEST/pulls/27
François
On 09/12/2024 07:05, François Dumont wrote:
On 04/12/2024 22:48, Jonathan Wakely wrote:
On 04/12/24 19:27 +0100, François Dumont wrote:
Hi
I&#x
On 04/12/2024 22:48, Jonathan Wakely wrote:
On 04/12/24 19:27 +0100, François Dumont wrote:
Hi
I've completed the synchronization with your equivalent PR for
std::list so here is the updated patch.
PR updated a couple of days ago.
Note that I've started to rework the patch for t
On 18/11/2024 19:24, François Dumont wrote:
On 16/11/2024 02:18, Jonathan Wakely wrote:
On Sat, 16 Nov 2024 at 01:09, Jonathan Wakely
wrote:
While working on fancy pointer support for the linked lists I noticed
they didn't have any debug assertions. This adds the obvious non-
On 16/11/2024 02:18, Jonathan Wakely wrote:
On Sat, 16 Nov 2024 at 01:09, Jonathan Wakely wrote:
While working on fancy pointer support for the linked lists I noticed
they didn't have any debug assertions. This adds the obvious non-empty
assertions to front(), back(), pop_front() and pop_back
ext_ptr.cc: New
test case.
Tested under Linux x64.
Note that I've also run the 23_containers tests on map, multimap,
multiset and set tweaking implementation
so that new types are being used when C++11 or later even if allocator
pointer type is a C pointer.
Ok to commit ?
François
On
Sounds like a very good idea.
Moreover friend declaration could be limited to another _Hashtable<>
type with same _Key, _Value and _Alloc types to be compatible.
On 08/11/2024 11:33, Jonathan Wakely wrote:
On Thu, 7 Nov 2024 at 22:18, Jonathan Wakely wrote:
I realised that _M_merge_unique an
On 04/11/2024 19:45, Jonathan Wakely wrote:
On Mon, 4 Nov 2024 at 18:30, François Dumont wrote:
On 21/10/2024 06:56, François Dumont wrote:
On 17/10/2024 23:11, Jonathan Wakely wrote:
On Thu, 17 Oct 2024 at 21:39, Jonathan Wakely wrote:
On Thu, 17 Oct 2024 at 20:52, François Dumont
On 21/10/2024 06:56, François Dumont wrote:
On 17/10/2024 23:11, Jonathan Wakely wrote:
On Thu, 17 Oct 2024 at 21:39, Jonathan Wakely
wrote:
On Thu, 17 Oct 2024 at 20:52, François Dumont
wrote:
Here is an updated version that compiles, I think, all your
Sorry but I'm not sure, is it also ok for the 3 backports ?
On 22/10/2024 22:43, Jonathan Wakely wrote:
On Tue, 22 Oct 2024 at 18:28, François Dumont wrote:
Hi
libstdc++: Always instantiate key_type to compute hash code [PR115285]
Even if it is possible to compute a hash
Hi
libstdc++: Always instantiate key_type to compute hash code [PR115285]
Even if it is possible to compute a hash code from the inserted
arguments
we need to instantiate the key_type to guaranty hash code consistency.
Preserve the lazy instantiation of the mapped_type in the
Reasoning is perfectly fine to me.
It's not a good news for me cause I plan to extend usages of
__niter_base to many algos to limit impact of _GLIBCXX_DEBUG mode at
runtime. If we have random access iterator we can be sure that
__glibcxx_requires_valid_range fully validated the range and so we
On 17/10/2024 23:11, Jonathan Wakely wrote:
On Thu, 17 Oct 2024 at 21:39, Jonathan Wakely
wrote:
On Thu, 17 Oct 2024 at 20:52, François Dumont
wrote:
Here is an updated version that compiles, I think, all your
feedbacks. It's much cleaner indeed.
T
On 17/10/2024 11:13, Giuseppe D'Angelo wrote:
Hello,
Il 17/10/24 06:32, François Dumont ha scritto:
As a side note you should provide your patches as .txt files so that any
email client can render it without going through an editor.
Apologies for that. Do you mean I should use text/
cator/ext_ptr.cc: New
test case.
Ok to commit ?
François
On 09/10/2024 00:02, Jonathan Wakely wrote:
On Tue, 8 Oct 2024 at 22:50, Jonathan Wakely
wrote:
On Thu, 1 Aug 2024 at 18:28, François Dumont
wrote:
Hi
Here is a proposal to add fancy pointer s
As a side note you should provide your patches as .txt files so that any
email client can render it without going through an editor.
And regarding the patch, I wonder what the std::move is for on the
returned value ?
Like this one:
+ {
+ return std::move(__lhs.append(__rhs));
+ }
Here is a fresh rebased version.
François
On 04/01/2024 06:50, François Dumont wrote:
Here is an updated version.
libstdc++: [_Hashtable] Avoid redundant usage of rehash policy
Bypass call to __detail::__distance_fwd and the check if rehash is
needed when
instantiating from an
On 02/10/2024 19:07, Jonathan Wakely wrote:
On Wed, 2 Oct 2024 at 17:39, Jonathan Wakely wrote:
On Wed, 25 Sept 2024 at 18:22, François Dumont wrote:
Hi
Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
will be accepted we will be able fix this long lasting issue
Hi
Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
will be accepted we will be able fix this long lasting issue that
std::stable_sort and std::inplace_merge are forcing the functor to take
const& parameters even when iterators used in range are not const ones.
This pa
Hi
Here is a proposal to add fancy pointer support in std::_Rb_tree container.
As you'll see there are still several usages of
pointer_traits<>::pointer_to. The ones in _M_header_ptr() are
unavoidable. The ones to extract a node or to return a node to the
allocator are more questionable. Are
(test01):
Remove test variable
and use 'no match' dg-error patter.
* testsuite/23_containers/set/operators/1_neg.cc (test01):
Likewise.
Comitted with you as author.
François
On 01/08/2024 09:26, Jonathan Wakely wrote:
On Thu, 1 Aug 2024 at 06:09, François Dum
Wed, 31 Jul 2024 at 21:59, Jonathan Wakely wrote:
On Wed, 31 Jul 2024 at 21:44, François Dumont wrote:
Committed as trivial.
Fix a compilation error that is not expected by the tests preserving
the expected ones.
The 'test' variable declaration is missing si
Committed as trivial.
Fix a compilation error that is not expected by the tests preserving
the expected ones.
The 'test' variable declaration is missing since commit
a9260b7eb688df43a724e25421ba40f35a89fee9 that removed the test global
variable in testsuite files.
libstdc++-v3/ChangeLog:
*
On 27/06/2024 22:30, Jonathan Wakely wrote:
On Thu, 27 Jun 2024 at 20:25, François Dumont wrote:
Thanks for the link, based on it I removed some of the nullptr usages
keeping only assignments.
That's not necessary. A nullable pointer type is equality comparable
with nullptr_t, and nu
Thanks for the link, based on it I removed some of the nullptr usages
keeping only assignments.
François
On 26/06/2024 23:41, Jonathan Wakely wrote:
On Wed, 26 Jun 2024 at 21:39, François Dumont wrote:
Hi
Here is my proposal to add support for fancy allocator pointer.
The only place where
Hi
Here is my proposal to add support for fancy allocator pointer.
The only place where we still have C pointers is at the
iterator::pointer level but it's consistent with std::list
implementation and also logical considering that we do not get
value_type pointers from the allocator.
I also
Hi
Still no time ?
Thanks
On 06/06/2024 19:02, François Dumont wrote:
No chance ?
On 22/05/2024 06:50, François Dumont wrote:
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the
pointers.
(_Hashtable_alloc::_M_deallocate_buckets): Add destroy of
buckets.
Tested under Linux x64, ok to commit ?
François
On 13/06/2024 20:58, Jonathan Wakely wrote:
On Thu, 13 Jun 2024 at 19:57, Jonathan Wakely wrote:
On Thu, 13 Jun 2024 at 18:40, François Dumont wrote:
Hi
Hi
Following your recent change here:
https://gcc.gnu.org/pipermail/libstdc++/2024-June/058998.html
I think we also need to fix the memset at bucket allocation level.
I did it trying also to be more fancy pointer friendly by running
__uninitialized_default_n_a on the allocator returned pointe
Hi
libstdc++: [_Hashtable] Optimize destructor
Hashtable destructor do not need to call clear() method that in addition to
destroying all nodes also reset all buckets to nullptr.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (~_Hashtable()): Replace clear call with
a _M_deallocate
No chance ?
On 22/05/2024 06:50, François Dumont wrote:
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword except in
_Prime_rehash_policy where it is preserved for
On 03/06/2024 18:20, Jonathan Wakely wrote:
On Mon, 3 Jun 2024 at 05:56, François Dumont wrote:
I hadn't try to make my patch as limited as possible to fix the problem,
indeed.
libstdc++: Fix -Wstringop-overflow warning coming from std::vector
[PR109849]
libstdc++-v3/Chan
k to commit ?
François
On 30/05/2024 13:07, Jonathan Wakely wrote:
On Thu, 30 May 2024 at 06:11, François Dumont wrote:
Looks like this new version works the same to fix the warning without
the issues reported here.
All 23_containers/vector tests run in C++98/14/20 so far.
Ok to commit once I'
in mind do not hesitate
to tell me.
François
On 28/05/2024 12:28, Jonathan Wakely wrote:
On 27/05/24 22:07 +0200, François Dumont wrote:
In C++98 this test fails with:
Excess errors:
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:
warn
.
Tested under Linux x86_64.
Ok to commit ?
François
On 28/05/2024 12:30, Jonathan Wakely wrote:
On Mon, 27 May 2024 at 05:37, François Dumont wrote:
Here is a new version working also in C++98.
Can we use a different solution that doesn't involve an explicit
template argument list for
/2024 22:18, Sam James wrote:
François Dumont writes:
In C++98 this test fails with:
For this, and your other -Wfree-nonheap-object patches, could you see if
it helps with any of the bugs reported for both -Wstringop-overflow and
-Wfree-nonheap-object in libstdc++? There's a bunch of (possi
In C++98 this test fails with:
Excess errors:
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing between 2 and 9223372036854775806 bytes into a region of size 0
overflows
/2024 16:17, Jonathan Wakely wrote:
On Thu, 23 May 2024 at 18:38, François Dumont wrote:
On 23/05/2024 15:31, Jonathan Wakely wrote:
On 23/05/24 06:55 +0200, François Dumont wrote:
As explained in this email:
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html
I experimented -
On 24/05/2024 16:17, Jonathan Wakely wrote:
On Thu, 23 May 2024 at 18:38, François Dumont wrote:
On 23/05/2024 15:31, Jonathan Wakely wrote:
On 23/05/24 06:55 +0200, François Dumont wrote:
As explained in this email:
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html
I
On 23/05/2024 15:31, Jonathan Wakely wrote:
On 23/05/24 06:55 +0200, François Dumont wrote:
As explained in this email:
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html
I experimented -Wfree-nonheap-object because of my enhancements on
algos.
So here is a patch to extend the
As explained in this email:
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html
I experimented -Wfree-nonheap-object because of my enhancements on algos.
So here is a patch to extend the usage of the _Guard type to other parts
of vector.
libstdc++: Use RAII to replace try/catc
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword except in
_Prime_rehash_policy where it is preserved for abi compatibility
reason.
Fix comment to explain
On 13/05/2024 10:34, Jonathan Wakely wrote:
On Mon, 13 May 2024, 07:30 Iain Sandoe, wrote:
> On 13 May 2024, at 06:06, François Dumont
wrote:
>
>
> On 07/05/2024 18:15, Iain Sandoe wrote:
>> Hi François
>>
>>> On 4 Ma
On 07/05/2024 18:15, Iain Sandoe wrote:
Hi François
On 4 May 2024, at 22:11, François Dumont wrote:
Here is the list of patches to restore gnu versioned namespace mode.
1/3: Bump gnu version namespace
This is important to be done first so that once build of gnu versioned
namespace is
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword except in
_Prime_rehash_policy where it is preserved for abi compatibility
reason.
Fix comment to explain that we need the computation of bucket index
noexcep
libstdc++: [_GLIBCXX_INLINE_VERSION] Use cxx11 abi [PR83077]
Use cxx11 abi when activating versioned namespace mode. To do so
support a new
configuration mode where !_GLIBCXX_USE_DUAL_ABI and
_GLIBCXX_USE_CXX11_ABI.
The main change is that std::__cow_string is now defined when
libstdc++: Review configuration options to control abi
--disable-libstdcxx-dual-abi default to 'new' abi mode.
--with-default-libstdcxx-abi consider the requested abi mode regardless
of --disable-libstdcxx-dual-abi usage.
libstdc++-v3/ChangeLog
* acinclude.m4 (G
libstdc++: Bump gnu versioned namespace to __9
libstdc++-v3/ChangeLog:
* acinclude.m4 (libtool_VERSION): Bump to 9:0:0.
* config/abi/pre/gnu-versioned-namespace.ver (GLIBCXX_8.0):
Replace by GLIBCXX_9.0.
Adapt all references to __8 namespace.
* c
Here is the list of patches to restore gnu versioned namespace mode.
1/3: Bump gnu version namespace
This is important to be done first so that once build of gnu versioned
namespace is fixed there is no chance to have another build of '__8'
version with a different abi than last successful '__
:
* include/std/iterator (__cpp_lib_null_iterators): Define
regardless of
_GLIBCXX_DEBUG.
* include/std/version (__cpp_lib_null_iterators): Likewise.
François
On 20/03/2024 10:02, Jonathan Wakely wrote:
On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
Thanks to you
wrote:
On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
Both committed now.
Just to confirm, those 2 last patches should be backported to gcc-13
branch, right ?
Yes please.
I might have a try to update version.h but if you want to do it before
don't hesitate.
You'll need to hav
_containers/vector/debug/n3644.cc: New test case.
Ok to commit ?
OK, thanks.
François
On 17/03/2024 17:52, François Dumont wrote:
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
debug mode?
After
/n3644.cc: New test case.
Ok to commit ?
François
On 17/03/2024 17:52, François Dumont wrote:
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
debug mode?
After this fix of local_iterator I think
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
debug mode?
After this fix of local_iterator I think we can indeed.
In fact the added 11316.cc was already passing for
unordered_set<>::local_iterator bu
With the patch, sorry.
On 14/03/2024 22:49, François Dumont wrote:
Hi
This is what I started to do.
For now I haven't touch to __cpp_lib_null_iterators definition as
_Safe_local_iterator still need some work.
libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
Consid
Hi
This is what I started to do.
For now I haven't touch to __cpp_lib_null_iterators definition as
_Safe_local_iterator still need some work.
libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
Consider range of value-initialized iterators as valid and empty.
libstdc++-v3/ChangeLog:
For those using my patch to build in gnu-versioned-namespace mode it
would be preferable not to have any failures when running testsuite.
libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg-error message
libstdc++-v3/ChangeLog:
* testsuite/20_util/function_objects/bind_back/11132
wrote:
On Mon, 19 Feb 2024, 08:12 Jonathan Wakely, wrote:
On Mon, 19 Feb 2024, 07:08 Stephan Bergmann,
wrote:
On 2/17/24 15:14, François Dumont wrote:
> Thanks for the link, tested and committed.
I assume this is the cause for the below failure now,
rt instead.
François
On 19/02/2024 09:21, Jonathan Wakely wrote:
On Mon, 19 Feb 2024, 08:12 Jonathan Wakely, wrote:
On Mon, 19 Feb 2024, 07:08 Stephan Bergmann,
wrote:
On 2/17/24 15:14, François Dumont wrote:
> Thanks for the link, tested and committed.
Thanks for the link, tested and committed.
On 15/02/2024 19:40, Jonathan Wakely wrote:
On Thu, 15 Feb 2024 at 18:38, François Dumont
wrote:
On 15/02/2024 14:17, Jonathan Wakely wrote:
On Wed, 14 Feb 2024 at 21:48, François Dumont
wrote:
On 14/02/2024 20:44
On 15/02/2024 14:17, Jonathan Wakely wrote:
On Wed, 14 Feb 2024 at 21:48, François Dumont
wrote:
On 14/02/2024 20:44, Jonathan Wakely wrote:
On Wed, 14 Feb 2024 at 18:39, François Dumont
wrote:
libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior
On 14/02/2024 20:44, Jonathan Wakely wrote:
On Wed, 14 Feb 2024 at 18:39, François Dumont
wrote:
libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior
std::__niter_base is used in _GLIBCXX_DEBUG mode to remove
_Safe_iterator<>
wrapper on random access iterator
libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior
std::__niter_base is used in _GLIBCXX_DEBUG mode to remove _Safe_iterator<>
wrapper on random access iterators. But doing so it should also preserve
original
behavior to remove __normal_iterator wrapper.
libstdc++-v3/ChangeLog:
*
++/90276] PSTL tests fail in Debug Mode
Date: Wed, 31 Jan 2024 19:09:02 +0100
From: François Dumont
To: redi at gcc dot gnu.org ,
fdum...@gcc.gnu.org
Here is the reason of the
20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc FAIL.
Maybe it fixes some other tests too, I need
/01/2024 11:10, Jonathan Wakely wrote:
On Mon, 29 Jan 2024 at 06:13, François Dumont wrote:
Hi
I'm trying to use _GLIBCXX_DEBUG_BACKTRACE to debug some crash in debug
mode.
So I buit library with --enable-libstdcxx-backtrace=yes
But when I build any test I have:
/usr/bin/ld: /tmp/cctvP
1月18日(木) 4:04 François Dumont :
Hi
Looks like a great finding to me, this is indeed a useless check,
thanks!
Have you any figures on the performance enhancement ? It might
help to get proper approval as gcc is currently in dev stage 4
that is to say only bug fixe
Hi
Looks like a great finding to me, this is indeed a useless check, thanks!
Have you any figures on the performance enhancement ? It might help to
get proper approval as gcc is currently in dev stage 4 that is to say
only bug fixes normally.
François
On 17/01/2024 09:11, Huanghui Nie wrote
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
François Dumont changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot
On 07/01/2024 21:53, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
On 07/01/2024 17:34, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
Hi
While working on the patch to use the cxx11 abi in gnu version namespace
mode I got a small
On 07/01/2024 17:34, Jonathan Wakely wrote:
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
Hi
While working on the patch to use the cxx11 abi in gnu version namespace
mode I got a small problem with this missing constructor. I'm not sure
that the main patch will be integrated in g
Hi
While working on the patch to use the cxx11 abi in gnu version namespace
mode I got a small problem with this missing constructor. I'm not sure
that the main patch will be integrated in gcc 14 so I think it is better
if I propose this patch independently.
libstdc++: Add __cow_string c
.
Ok to commit ?
François
On 21/12/2023 23:17, Jonathan Wakely wrote:
On Thu, 23 Nov 2023 at 21:59, François Dumont wrote:
libstdc++: [_Hashtable] Avoid redundant usage of rehash policy
Bypass call to __detail::__distance_fwd and the check if rehash is
needed when
assigning a
On 21/12/2023 23:07, Jonathan Wakely wrote:
On Thu, 23 Nov 2023 at 21:59, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword. For
_Prime_rehash_policy methods are exported from the
t now as I still hope that the patch to
move to cxx11 abi in gnu versioned namespace will be integrated so with
its implied version bump.
On Wed, 20 Dec 2023 at 06:10, François Dumont wrote:
Here is a new version of this patch.
The previous one had some flaws that were unnoticed by test
Here is a new version of this patch.
The previous one had some flaws that were unnoticed by testsuite tests,
only the performance tests were spotting it. So I'm adding checks on the
consistency of the unordered containers in this patch.
I also forget to signal that after this patch gnu versio
On 07/12/2023 14:41, Jonathan Wakely wrote:
On Wed, 6 Dec 2023 at 20:55, François Dumont wrote:
I think I still got no feedback about this cleanup proposal.
Can you remind me why we have all those different functions in
predefined_ops.h in the first place? I think it was to avoid having
two
I think I still got no feedback about this cleanup proposal.
Here is a new version.
François
On 15/06/2023 07:07, François Dumont wrote:
I think we all agree that __gnu_cxx::__ops needed to be reimplemented,
here it is.
Note that I kept the usage of std::ref in , and .
libstdc
libstdc++: [_Hashtable] Extend the small size optimization
A number of methods were still not using the small size
optimization which
is to prefer an O(N) research to a hash computation as long as N is
small.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Mov
libstdc++: [_Hashtable] Prefer to insert after last node
When inserting an element into an empty bucket we currently insert
the new node
after the before-begin node so in first position. The drawback of
doing this is
that we are forced to update the bucket that was containing th
libstdc++: [_Hashtable] Avoid redundant usage of rehash policy
Bypass call to __detail::__distance_fwd and the check if rehash is
needed when
assigning an initializer_list to an unordered_multimap or
unordered_multiset.
libstdc++-v3/ChangeLog:
* include/bits/hasht
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword. For
_Prime_rehash_policy methods are exported from the library, we need to
keep their const qualifier, so adapt implementation to update
previously
mutable
libstdc++: [_Hashtable] Enhance/Add performance benches
diff --git a/libstdc++-v3/testsuite/performance/23_containers/insert/54075.cc
b/libstdc++-v3/testsuite/performance/23_containers/insert/54075.cc
index f8fcce31609..f2d975ecdaf 100644
--- a/libstdc++-v3/testsuite/performance/23_containers/in
This is a series of patch to enhance _Hashtable insertion operations
that I'd like to see in gcc 14. I've already submitted something similar
a couple of months ago but it is quite a revisited version.
1/5 Is adding benches to show the impact of the different optimizations
2/5 Implementation i
Following several remarks on a previous patch of _Hashtable I considered
clarifying its implementation.
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword. For
_Prime_rehash_policy methods are exported from the libr
Another proposal to use RAII rather than __try/__catch block.
libstdc++: [_Hashtable] Use RAII type to guard node while constructing value
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h
(struct _NodePtrGuard<_HashtableAlloc, _NodePtr>): New.
(_ReuseAllocNode::
On 07/11/2023 00:28, Jonathan Wakely wrote:
On Mon, 6 Nov 2023 at 21:39, François Dumont wrote:
Noticed looking for other occasion to replace __try/__catch with RAII
helper.
libstdc++: [_Hashtable] Add missing node destructor call
libstdc++-v3/ChangeLog
Noticed looking for other occasion to replace __try/__catch with RAII
helper.
libstdc++: [_Hashtable] Add missing node destructor call
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_allocate_node): Add missing call to
node des
On 30/10/2023 14:45, Jonathan Wakely wrote:
On Sun, 29 Oct 2023 at 21:11, François Dumont wrote:
This fixes handle_contract_violation under versioned namespace mode.
Tested under Linux x64 and confirmed to also fix Darwin build.
libstdc++: [_GLIBCXX_INLINE_VERSION] Provide
On 30/10/2023 14:58, Jonathan Wakely wrote:
On Sun, 29 Oct 2023 at 21:25, François Dumont wrote:
libstdc++: [_GLIBCXX_INLINE_VERSION] Add emul TLS symbols
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver: Add missing emul TLS
symbols.
Please put a comment
libstdc++: [_GLIBCXX_INLINE_VERSION] Add emul TLS symbols
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver: Add missing emul TLS
symbols.
François
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespa
This fixes handle_contract_violation under versioned namespace mode.
Tested under Linux x64 and confirmed to also fix Darwin build.
libstdc++: [_GLIBCXX_INLINE_VERSION] Provide handle_contract_violation
symbol
libstdc++-v3/ChangeLog:
* src/experimental/contract.cc
[_GLIBCXX_I
On 26/10/2023 12:43, Jonathan Wakely wrote:
On 26/10/23 07:18 +0200, François Dumont wrote:
libstdc++: [_Hashtable] Use RAII type to manage rehash functor state
Replace usage of __try/__catch with a RAII type to restore rehash
functor
state when needed.
Generally I really like
libstdc++: [_Hashtable] Use RAII type to manage rehash functor state
Replace usage of __try/__catch with a RAII type to restore rehash
functor
state when needed.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_RehashStateGuard): New.
(_Inser
Hi
Still no one to complete this review ?
Thanks
On 07/10/2023 21:32, François Dumont wrote:
I've been told that previous patch generated with 'git diff -b' was
not applying properly so here is the same patch again with a simple
'git diff'.
On 07/10/2023 14:25, F
Committed with the advised changes.
Ok, I'll backport next week.
Thanks
On 19/10/2023 10:05, Jonathan Wakely wrote:
On Thursday, 19 October 2023, François Dumont
wrote:
> libstdc++: [_Hashtable] Do not reuse untrusted cached hash code
>
> On merge reuse merged node cached
libstdc++: [_Hashtable] Do not reuse untrusted cached hash code
On merge reuse merged node cached hash code only if we are on the same
type of
hash and this hash is stateless. Usage of function pointers or
std::function as
hash functor will prevent this optimization.
libstdc++-v3/ChangeLog
Now that abi breakage is fixed and hoping that Friday is review day :-)
Ping !
On 17/09/2023 22:41, François Dumont wrote:
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
Hi Iain
On 11/10/2023 09:30, Iain Sandoe wrote:
Hi François,
On 11 Oct 2023, at 05:49, François Dumont wrote:
On 08/10/2023 15:59, Iain Sandoe wrote:
On 23 Sep 2023, at 21:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem in
li
On 08/10/2023 15:59, Iain Sandoe wrote:
Hi François,
On 23 Sep 2023, at 21:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem in
libstdc++ testsuite.
testsuite: Add optional libstdc++ version namespace in expected diagnostic
1 - 100 of 1021 matches
Mail list logo
