Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-11 Thread Jonathan Wakely via Gcc-patches
On Thu, 11 Nov 2021 at 21:33, François Dumont wrote: > On 11/11/21 9:41 pm, Jonathan Wakely wrote: > > > > On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely wrote: > >> >> >> On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote: >> >>> >>> >>> On Mon, 8 Nov 2021 at 21:36, François Dumont >>> wrote:

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-11 Thread François Dumont via Gcc-patches
On 11/11/21 9:41 pm, Jonathan Wakely wrote: On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely > 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 mailto:frs.dum...

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-11 Thread Jonathan Wakely via Gcc-patches
On Wed, 10 Nov 2021 at 11:55, Jonathan Wakely wrote: > > > On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote: > >> >> >> On Mon, 8 Nov 2021 at 21:36, François Dumont >> wrote: >> >>> Yet another version this time with only 1 guard implementation. The >>> predicate to invalidate the safe iterat

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-10 Thread Jonathan Wakely via Gcc-patches
On Tue, 9 Nov 2021 at 16:25, Jonathan Wakely wrote: > > > On Mon, 8 Nov 2021 at 21:36, François Dumont wrote: > >> Yet another version this time with only 1 guard implementation. The >> predicate to invalidate the safe iterators has been externalized. >> >> Ok to commit ? >> > > I like this vers

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-10 Thread Jonathan Wakely via Gcc-patches
On Wed, 10 Nov 2021 at 05:47, François Dumont wrote: > On 09/11/21 5:25 pm, Jonathan Wakely wrote: > > > > On Mon, 8 Nov 2021 at 21:36, François Dumont wrote: > >> Yet another version this time with only 1 guard implementation. The >> predicate to invalidate the safe iterators has been externali

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Wed, 10 Nov 2021, 05:45 François Dumont, wrote: > I can't see any clue on how my commit can have had an impact on below code. > Agreed. > I don't think libstdc++ hash table has any relation with gcc hash table. > Correct, it's totally unrelated. And "section type conflict" can't be caused

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread François Dumont via Gcc-patches
On 09/11/21 5:25 pm, Jonathan Wakely wrote: On Mon, 8 Nov 2021 at 21:36, François Dumont > wrote: Yet another version this time with only 1 guard implementation. The predicate to invalidate the safe iterators has been externalized. Ok to commit ? I

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread François Dumont via Gcc-patches
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-p

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread H.J. Lu via Gcc-patches
On Mon, Nov 8, 2021 at 1:37 PM François Dumont via Gcc-patches wrote: > > Yet another version this time with only 1 guard implementation. The > predicate to invalidate the safe iterators has been externalized. > > Ok to commit ? > This may have broken GCC bootstrap on Linux/x86-64: https://gcc.g

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Mon, 8 Nov 2021 at 21:36, François Dumont wrote: > Yet another version this time with only 1 guard implementation. The > predicate to invalidate the safe iterators has been externalized. > > Ok to commit ? > I like this version a lot - thanks for persisting with it. OK to commit, thanks. A

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-08 Thread François Dumont via Gcc-patches
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 i

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-06 Thread François Dumont via Gcc-patches
You were right to delay your reply. Here is a new version with less code duplication and a bug fix in the new _UContMergeGuard where we were using it->second rather than it->first to get the key. Note also that the change to _M_merge_multi implementation is also important because otherwise we

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-25 Thread François Dumont via Gcc-patches
New patch with the proposed workaround below. I also slightly change the _M_merge_multi implementation so that if the new hash code computation raise an exception the node is simply not extracted rather than extracted and then released. This way, if it takes place on the 1st moved node the _GL

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-21 Thread François Dumont via Gcc-patches
On 21/10/21 6:55 pm, Jonathan Wakely wrote: On Thu, 21 Oct 2021 at 17:52, François Dumont > 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 a node is

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-21 Thread Jonathan Wakely via Gcc-patches
On Thu, 21 Oct 2021 at 17:52, François Dumont 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 a node is being extracted. This way invalidation is only done by > comparing nodes, no need to

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-21 Thread François Dumont via Gcc-patches
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 a node is being extracted. This way invalidation is only done by comparing nodes, no need to compute hash code for this operation. The only drawback is

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-16 Thread Jonathan Wakely via Gcc-patches
On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++, < libstd...@gcc.gnu.org> wrote: > Hi > > Here is the new proposal. My only concern is that we are also using > hash or equal_to functors in the guard destructor. > Can we catch any exception there, invalidate all iterators, and not r

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-16 Thread François Dumont via Gcc-patches
Hi     Here is the new proposal. My only concern is that we are also using hash or equal_to functors in the guard destructor.     I am going to enhance merge normal implementation to make use of the cached hash code when hash functors are the same between the source and destination of nodes.

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-14 Thread Jonathan Wakely via Gcc-patches
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 unordered containers need a dedicated merge > implementation > so that any existing iterator on the transfered nodes i

[PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-10-13 Thread François Dumont via Gcc-patches
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