[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316 François Dumont changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #4 from François Dumont --- Similar issues with N3344 also fixed and back-ported to GCC 13.
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #2 from François Dumont --- Is there any unmentioned prerequisite to reproduce this bug ? I cannot. Maybe thanks to PR11477 this PR could be closed too.
[Bug libstdc++/112477] [13/14 Regression] Assignment of value-initialized iterators differs from value-initialization
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 gnu.org --- Comment #8 from François Dumont --- Hi I'm going to have a look but if you wish to contribute do not hesitate. Thanks for the report.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #20 from François Dumont --- I run make check-c++ before and after my patch and I see no regression. I even have less failures with the patch even if I haven't check yet why. So I think the patch is quite safe, just waiting for validation now.
[Bug c++/111524] New: Missing support for inline namespace in spellcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111524
Bug ID: 111524
Summary: Missing support for inline namespace in spellcheck
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fdumont at gcc dot gnu.org
Target Milestone: ---
When spellcheck is trying to find out what mistake the dev made inline
namespace are not considered.
To reproduce you just need to build g++/libstdc++ with:
--enable-languages=c++ --enable-symvers=gnu-versioned-namespace
so that you have the std::__8:: inline namespace for mostly all libstdc++
symbols.
Then running 'make check-c++' several spellcheck tests will start to fail like:
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C: In
function 'void* allocate(std::size_t)':
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C:7:15:
error: 'allocate' is not a member of 'std'; did you mean 'allocate'?
return std::allocate().allocate(n); // { dg-error ".allocate. is not a
member of .std.; did you mean 'allocator'\\?" }
^~~~
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/spellcheck-pr78656.C:5:7: note:
'allocate' declared here
void* allocate(std::size_t n)
^~~~
It's not proposing std::allocator anymore as it is in fact std::__8::allocator.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #17 from François Dumont --- (In reply to Iain Sandoe from comment #15) > > many of the c++ fails are of this form: > > contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to > `handle_contract_violation(std::experimental::contract_violation const&)' I'm surprised that my patch can have an impact on the C++ front end but I'll give it a try. Did you first run those without my patches ? I've never run the C++ tests. They can be run without a proper libstdc++ build, no ?
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #14 from François Dumont --- Good news then. On my side I only had some failures due to a faulty friend declaration in gnu-versioned-namespace mode in for which I've submitted a patch: https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from François Dumont --- Considering that explosion is taking place in your code built with a gcc post-11 while calling _M_next() on a _Hashtable instance node coming from a .so built with a gcc pre-11 version I think your solution should work. I'll send a patch proposal to mailing list.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #10 from François Dumont --- This is because you are facing the PR65762 issue. I just attached a path proposal to it that you need to apply too to be able to run your test. You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made cxx11 abi the default in this case.
[Bug libstdc++/65762] --with-default-libstdcxx-abi=c++11 is silently ignored when --disable-libstdcxx-dual-abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65762 --- Comment #3 from François Dumont --- Created attachment 55834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55834=edit Patch proposal Here is a proposal that I'll submit on libstdc++ mailing list once PR83077 is fixed. Note that in addition to allowing the configuration reported here it also make --disable-libstdcxx-dual-abi use cxx11 abi per default. I'm not sure that this part will be accepted.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #3 from François Dumont --- For sure _Hash_node layout didn't change, that's why I couldn't think of any abi issue here. I see that you already had the solution ! It was some kind of test then, I failed :-). Did you try it ? If you already have the use case on your side to reproduce the explosion it should be rather easy to confirm that adding: [[__gnu__::__always_inline__]] on _M_next member fixes the issue.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #7 from François Dumont --- Sure, if you follow the email thread you'll see my latest patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628399.html
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 François Dumont changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- A 3 years old abi regression seems difficult to fix now. To do so we would need to break abi again. It seems to be a limited issue as you need a non-optimized build. The only impacted member is the _M_next() which is a simple static_cast, I'm very surprised that it's not always inlined even if non-optimized. Apart perhaps documenting it I cannot think of anything to do.
[Bug libstdc++/91263] unordered_map and unordered_set operator== double key comparison causes exponential behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91263 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from François Dumont --- Can be close now.
[Bug libstdc++/107189] Inconsistent range insertion implementations in std::_Rb_tree in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107189 François Dumont changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #3 from François Dumont --- I am making this bug resolved for the useless _Alloc_node instance. Regarding the inconsistent implementation feel free to open another issue with more explanations. Thanks
[Bug libstdc++/103621] stable_sort could call std::__merge_sort_with_buffer directly in typical case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103621 François Dumont changed: What|Removed |Added Target Milestone|--- |13.0 Status|UNCONFIRMED |RESOLVED CC||fdumont at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from François Dumont --- I think it has been fixed by: commit 63d182fb86e47323ac50d9368845d712e1f7da89 Author: François Dumont Date: Thu Jan 21 19:30:47 2021 +0100 libstdc++: Enhance branching in std::inplace_merge and std::stable_sort When we manage to allocate a buffer of the expected size we can simplify the code to perform the expected algorithm. libstdc++-v3/ChangeLog: * include/bits/stl_algo.h (__merge_adaptive): Adapt to merge only when buffer is large enough.. (__merge_adaptive_resize): New, adapt merge when buffer is too small. (__inplace_merge): Adapt, use latter. (__stable_sort_adaptive): Adapt to sort only when buffer is large enough. (__stable_sort_adaptive_resize): New, adapt sort when buffer is too small. (__stable_sort): Adapt, use latter. Let us know otherwise.
[Bug libstdc++/107189] Inconsistent range insertion implementations in std::_Rb_tree in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107189
François Dumont changed:
What|Removed |Added
Last reconfirmed||2022-10-12
Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot
gnu.org
Ever confirmed|0 |1
CC||fdumont at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from François Dumont ---
Code looks perfectly consistent to me. There is just this _Alloc_node
instantiation to remove.
Why do you want to call the _M_emplace_hint_{unique,equal} ? I rather wondered
why the __is_same_value_type alternatives are doing so just to pass end() as a
hint. And the answer is just that it is more convenient. Look at the
_M_insert_unique overloads to see that the one called is the most convenient
one.
Thanks for the report.
[Bug libstdc++/105717] [10/11/12/13 Regression] cannot create unordered_map from range of types convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|10.4|13.0 CC||fdumont at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- libstdc++: [_Hashtable] Insert range of types convertible to value_type PR 105717 Fix insertion of range of instances convertible to value_type. libstdc++-v3/ChangeLog: PR libstdc++/105717 * include/bits/hashtable_policy.h (_ConvertToValueType): New. * include/bits/hashtable.h (_Hashtable<>::_M_insert_unique_aux): New. (_Hashtable<>::_M_insert(_Arg&&, const _NodeGenerator&, true_type)): Use latters. (_Hashtable<>::_M_insert(_Arg&&, const _NodeGenerator&, false_type)): Likewise. (_Hashtable(_InputIterator, _InputIterator, size_type, const _Hash&, const _Equal&, const allocator_type&, true_type)): Use this.insert range. (_Hashtable(_InputIterator, _InputIterator, size_type, const _Hash&, const _Equal&, const allocator_type&, false_type)): Use _M_insert. * testsuite/23_containers/unordered_map/cons/56112.cc: Check how many times conversion is done. * testsuite/23_containers/unordered_map/insert/105717.cc: New test. * testsuite/23_containers/unordered_set/insert/105717.cc: New test.
[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088 François Dumont changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from François Dumont --- Fix with this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2c43f5ec9db163696de8691eb529df06c4999bcc libstdc++: Limit allocation on iterator insertion in Hashtable [PR 96088] When inserting into unordered_multiset or unordered_multimap first instantiate the node to store and compute the hash code from it to avoid a potential intermediate key_type instantiation. When inserting into unordered_set or unordered_map check if invoking the hash functor with container key_type is noexcept and invoking the same hash functor with key part of the iterator value_type can throw. In this case create a temporary key_type instance at Hashtable level and use it to compute the hash code. This temporary instance is moved to the final storage location if needed. libstdc++-v3/ChangeLog: PR libstdc++/96088 * include/bits/hashtable_policy.h (_Select2nd): New. (_NodeBuilder<>): New. (_ReuseOrAllocNode<>::operator()): Use variadic template args. (_AllocNode<>::operator()): Likewise. * include/bits/hashtable.h (_Hashtable<>::__node_builder_t): New. (_Hashtable<>::_M_insert_unique<>(_Kt&&, _Arg&&, const _NodeGenerator&)): New. (_Hashtable<>::_S_forward_key): New. (_Hashtable<>::_M_insert): Use latter. (_Hashtable<>::_M_insert(const_iterator, _Arg&&, const _NodeGenerator&, false_type)): Instantiate node first, compute hash code second. * testsuite/23_containers/unordered_map/96088.cc: New test. * testsuite/23_containers/unordered_multimap/96088.cc: New test. * testsuite/23_containers/unordered_multiset/96088.cc: New test. * testsuite/23_containers/unordered_set/96088.cc: New test. * testsuite/util/replacement_memory_operators.h (counter::_M_increment): New. (counter::_M_decrement): New. (counter::reset()): New.
[Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #13 from François Dumont --- Fixed on gcc-10 branch by this commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ab83ce42ea0b2fbc09d51b7bd5e69905dcaa2041.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from François Dumont --- Yes, when I introduced __dp_sign_max_size in the _Distance_precision enum I forgot to adapt some code.
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 --- Comment #6 from François Dumont --- Thanks for the feedback. If this is still a problem for you after this enhancement you should perhaps try the _Power2_rehash_policy provided as an extension. In testsuite/23_containers/unordered_set/insert/hash_policy.cc you'll see an example with a unordered_set like container defined as: template using unordered_set_power2_rehash = std::_Hashtable<_Value, _Value, _Alloc, std::__detail::_Identity, _Pred, _Hash, std::__detail::_Mask_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Power2_rehash_policy, std::__detail::_Hashtable_traits>; As stated by its name _Power2_rehash_policy will make sure that number buckets is a power of 2 and so make the modulo much trivial.
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from François Dumont --- This should be considered as fixed now.
[Bug libstdc++/98466] Debug Mode iterators for unordered containers do not implement N3644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98466 François Dumont changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from François Dumont --- Fully fixed
[Bug libstdc++/70303] Value-initialized debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303 François Dumont changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #7 from François Dumont --- Main issue fixed as part of PR 98466 and 33a1e511b57465d898429740377466894a0b247d fixed the last part for deque::iterator - operator.
[Bug libstdc++/70303] Value-initialized debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303 François Dumont changed: What|Removed |Added CC||fdumont at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #6 from François Dumont --- After fixing the duplicate PR 98466 std::vector::iterator is ok but std::deque::iterator seems to be broken still. Taking it.
[Bug libstdc++/98466] Debug Mode iterators for unordered containers do not implement N3644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98466 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Last reconfirmed||2020-12-29 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/83938] Speed up inplace_merge() algorithm & fix inefficient logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83938 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from François Dumont --- Git commit for this PR hasn't been detected so here it is: commit ba23e045fcb820e8d32dee361c4d048604d8d599 Author: François Dumont Date: Wed Jan 22 17:55:54 2020 +0100 libstdc++: Limit memory allocation in stable_sort/inplace_merge (PR 83938) Reduce memory allocation in stable_sort/inplace_merge algorithms to what is needed by the implementation. Co-authored-by: John Chang libstdc++-v3/ChangeLog: PR libstdc++/83938 * include/bits/stl_tempbuf.h (get_temporary_buffer): Change __len computation in the loop to avoid truncation. * include/bits/stl_algo.h: (__inplace_merge): Take temporary buffer length from smallest range. (__stable_sort): Limit temporary buffer length. * testsuite/25_algorithms/inplace_merge/1.cc (test4): New. * testsuite/performance/25_algorithms/stable_sort.cc: Test stable_sort under different heap memory conditions. * testsuite/performance/25_algorithms/inplace_merge.cc: New test. The added performance test didn't show any enhancement for the algo change so only the innefficiency has been fixed.
