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
Author: TC
Date: Wed Sep 6 19:31:55 2023 +0200
libstdc++: Force _Hash_node_value_base methods inline to fix abi
(PR111050)
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
changed _Hash_node_value_base to no longer derive from
_Hash_node_base,
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
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 mode are due to
those
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. I would prefer thi
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
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
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 abi issue is fixe
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 d
I've now prepared the patch to support following config:
--disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new
and so detected yet another problem with src/c++98/compatibility.cc. We
need basic_istream<>::ignore(streamsize) definitions that rely here but
not the rest of it.
François
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
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 not fixing an
Here is the updated and tested patch.
On 21/08/2023 20:07, Jonathan Wakely wrote:
On Mon, 21 Aug 2023 at 18:05, François Dumont via Libstdc++
wrote:
Hi
Here is a propocal to fix tests sensitive to libstdc++ internal allocations.
Surely the enter() and exit() calls should be a constructor and
Hi
Here is a propocal to fix tests sensitive to libstdc++ internal allocations.
Tested by restoring allocation in tzdb.cc.
As announced I'm also adding a test to detect such allocations. If it is
ok let me know if you prefer to see it in a different place.
libstdc++: Fix tests relying on
Here is a rebased patch following the resize_and_overwrite change.
I confirm that tests are now fixed after the change in tzdb.cc.
I'll prepare a fix for those tests still but preparing also a test to
detect allocations in the lib.
François
On 17/08/2023 21:44, Jonathan Wakely wrote:
On Thu
On 17/08/2023 19:22, Jonathan Wakely wrote:
On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
wrote:
Here is the fixed patch tested in all 3 modes:
- _GLIBCXX_USE_DUAL_ABI
- !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI
- !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI
I do
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-inst.cc for the std::__cow_string definition from .
The asser
Here is another version with enhanced sizeof/alignof static_assert in
string-inst.cc for the std::__cow_string definition from .
The assertions in cow-stdexcept.cc are now checking the definition which
is in the same file.
On 13/08/2023 15:27, François Dumont wrote:
Here is the fixed patch t
Here is the fixed patch tested in all 3 modes:
- _GLIBCXX_USE_DUAL_ABI
- !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI
- !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI
I don't know what you have in mind for the change below but I wanted to
let you know that I tried to put COW std::basic
I hadn't tested the most basic default configuration and it is failing,
I need some more time yet.
François
On 10/08/2023 07:13, François Dumont wrote:
Hi
I've eventually completed this work.
This evolution will allow to build libstdc++ without dual abi and
using cxx11 abi. For the moment
Hi
I've eventually completed this work.
This evolution will allow to build libstdc++ without dual abi and using
cxx11 abi. For the moment such a config is only accessible through the
--enable-symvers=gnu-versioned-namespace configuration.
libstdc++: [_GLIBCXX_INLINE_VERSION] Use cxx11 ab
libstdc++: [_GLIBCXX_INLINE_VERSION] Add __cxa_call_terminate symbol export
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver: Add __cxa_call_terminate
symbol export.
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu
Committed as obvious.
libstdc++: Fix several preprocessor directives
A wrong usage of #define in place of a #error seems to have been
replicated
at different places in source files.
libstdc++-v3/ChangeLog:
* src/c++11/compatibility-ldbl-facets-aliases.h: Replace
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 drawback of
doing this is
that we are forced to update the bucket that was containing th
On 18/07/2023 08:27, Ken Matsui via Libstdc++ wrote:
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc (trait_expr_valu
It seems rather logical cause std::disjunction is supposed to avoid
instantiations but in case of:
std::disjunction, std::is_null_pointer<_Tp>>
you'll avoid std::is_null_pointer instantiation only for 'void' type and
at the price of instantiating std::disjunction so 2 instantiations at
best b
On 17/07/2023 06:48, Ken Matsui wrote:
On Sun, Jul 16, 2023 at 5:32 AM François Dumont wrote:
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLo
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch optimizes the performance of the is_fundamental trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_fundamental_v): Use __is_arithmetic
built-in tr
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_arithmetic): Use __is_arithmetic
built-in trait.
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc (trait_expr_valu
On 10/07/2023 07:23, Ken Matsui via Libstdc++ wrote:
This patch implements built-in trait for std::is_pointer.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likew
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++: Reimplement __gnu_cxx::__ops operators
Replace functors using iterators as input to adopt functors that
are matching the same Standard ex
On 13/06/2023 00:22, Ken Matsui via Libstdc++ wrote:
This patch gets std::is_object to dispatch to new built-in traits,
__is_function, __is_reference, and __is_void.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_object): Use new built-in traits,
__is_function, __is_refe
Same remark for all your alike patches.
On 11/06/2023 04:43, Ken Matsui via Libstdc++ wrote:
This patch gets std::is_reference to dispatch to new built-in trait
__is_reference.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_reference): Use __is_reference built-in
trait.
On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
versions from the latestp list, as no more symbols should be added to
those now.
libstdc++-v3/
Ok, push done.
Even after full rebuild those tests are still UNRESOLVED on my system.
Yes, I also noticed that I could remove this check. I'll propose it later.
François
On 02/06/2023 09:43, Jonathan Wakely wrote:
On Fri, 2 Jun 2023 at 08:33, François Dumont wrote:
I haven't been able to
I haven't been able to reproduce so far.
Here is however a patch that I think will fix the problem. At least
failing tests are UNRESOLVED on my system.
libstdc++: Fix broken _GLIBCXX_PARALLEL mode
Add missing include in .
Detect availability of in tests needing it to make them
It's of course not as easy as I thought.
I would never have detected this problem on my system because I'm
missing omp.h.
I've implemented and added a:
// { dg-require-effective-target omp }
so that now those tests are UNRESOLVED rather than PASS.
Now I've install OMP and try to rebuild lib
Sorry, I had fully tested the move from bits/stl_algo.h to
bits/stl_algobase.h.
But it appears that the script I used to run the tests after the other move
has not done what I expected.
I'll provide the patch shortly.
Le jeu. 1 juin 2023 à 14:06, Jonathan Wakely a écrit :
>
>
> On Thu, 1 Jun
libstdc++: Reduce inclusion to
Move the std::search definition from stl_algo.h to stl_algobase.h and use
the later in .
For consistency also move std::__parallel::search and associated helpers
from
to so that
std::__parallel::search
is accessible along with std::search.
libstdc++-v3/Cha
On 22/05/2023 22:55, Jonathan Wakely wrote:
On Mon, 22 May 2023 at 21:51, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
I was thinking that it might be nice to get rid of
predefined_ops.h content.
So here is a start with __negate. Drawback is that stl
I was thinking that it might be nice to get rid of predefined_ops.h content.
So here is a start with __negate. Drawback is that stl_algo.h has to
include . For now I just get rid of stl_algo.h include in
to rather use stl_algobase.h. But maybe it would be better
to also isolate std::not_fn in
Hi
Rather than providing a series of patches for _Hashtable I prefer to
submit them one by one. It will maximize the chances to have some of
them in gcc 14.
I'm starting with this simple patch to do some cleanup in the current
implementation to ease compiler optimizations by making some meth
I had totally forgotten about it myself. The occasion to take a fresh
look at it.
Here is a new version considering 1st pubseekoff call returned value to
find out if it can be used. I removed the check/comparison with 2nd call
result as it's not usable. In new 4_neg.cc test case if I ask to ad
Just forget about this patch, bad idea.
The key_type might have additional data not used for the comparison.
This data would not be preserved if we were inserting the already stored
equivalent key instead of the user provided.
On 22/02/23 07:08, François Dumont wrote:
This one is a refineme
Replying to my own questions.
This use case is not valid from a Standard point of view. So not a bug
and no need to deal with that before next stage 1.
The question left is either we want to support it ?
François
On 23/02/23 22:14, François Dumont wrote:
Hi
Based on my work on PR 96088 for
Hi
Based on my work on PR 96088 for std::map I imagine this use case of
inserting a range of keys into an associative container. It behaves as
operator[] by inserting a default value for each key.
I wonder if the Standard says that it should work. Or maybe we want to
support it ?
I haven't
This one is a refinement for multimap/multiset.
It allows to have share the same key if managed with ref counting like
the cow string.
libstdc++: [_Rb_tree] Limit allocations on equal insertions [PR 96088]
When inserting the same key several times prefer to insert the new
entry using
Here is eventually a working proposal.
Compared to the unordered container approach we need to find out what
type is going to be used to call the comparer. Otherwise we might
reinstantiate a temporary each time we call the comparer. For example in
case of const char* insertion with a less comp
On 17/02/23 09:01, Alexandre Oliva via Libstdc++ wrote:
On Feb 17, 2023, Alexandre Oliva wrote:
On vxworks, after destroying the semaphore used to implement a mutex,
__gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
__throw_concurrence_lock_error. Nothing ensures the mutex_pool
mu
On 03/02/23 15:50, Jonathan Wakely wrote:
On Wed, 25 Jan 2023 at 18:38, François Dumont wrote:
Let's submit a proper patch proposal then.
The occasion for me to ask if there is any reason for cow string not
being C++11 allocator compliant ? Just lack of interest ?
Mostly lack of interest, but
This is PR 96088 but this time for _Rb_tree based containers.
I guess it won't go in for the moment but I wanted to submit it already
because of the changes I had to do in stl_functions.h. It sounds like
missing parts for C++11 move-semantic. I still need to run all tests to
see if they can ha
Let's submit a proper patch proposal then.
The occasion for me to ask if there is any reason for cow string not
being C++11 allocator compliant ? Just lack of interest ?
I wanted to consider it to get rid of the __gnu_debug::_Safe_container
_IsCxx11AllocatorAware template parameter.
lib
On 23/01/23 10:22, Jonathan Wakely wrote:
On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++
wrote:
libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
Creating a safe iterator from a normal iterator is done within the
library where we
already know that it
libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
Creating a safe iterator from a normal iterator is done within the
library where we
already know that it is done correctly. The rare situation where a
user would use safe
iterators for his own purpose is non-Standard
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 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 Dumon
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 (o
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 for an
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 chance
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 chance for the instantiation to be
elided when it is implemented like in the _Safe_local_iterator:
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
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]
Looks perfect to me, thanks.
On 06/12/22 22:44, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 18:00, François Dumont wrote:
On 30/11/22 14:07, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
On Wed, 30 Nov
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 (once patch validated) I'd like
to propose this patch again.
Note that I'am adding a check on pretty printer
On 30/11/22 14:07, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
wrote:
Good catch, then we also need this patch.
Is it worth printing an err
On 30/11/22 14:07, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
wrote:
Good catch, then we also need this patch.
Is it worth printing an err
On 28/11/22 19:35, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
std/format/formatter/requirements.cc
std/format/functions/form
I forgot to add the patch but as you already made another feedback I'll
clean my patch first.
On 28/11/22 19:43, François Dumont wrote:
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Li
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
On 28/11/22 14:39, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely
wrote:
On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
std/format/formatter/requirements.cc
std/format/functions/format.cc
std/format/functions/format_to_n.cc
std/format/functions/size.cc
std/format/functions/vformat_to.cc
std/format/string.cc
Note that symbols used in for __ibm12
libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
libstdc++-v3/ChangeLog
* testsuite/20_util/bind/ref_neg.cc: Adapt dg-prune-output message.
* testsuite/20_util/function/cons/70692.cc: Adapt dg-error message.
Ok to commit ?
François
diff --git a/libstdc++-v3/testsuit
On 19/11/22 14:11, Jonathan Wakely wrote:
On Sat, 19 Nov 2022 at 13:03, François Dumont via Libstdc++
wrote:
Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2649:
note: ca
Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2649:
note: candidate: 'template bool std::__9::isxdigit(_CharT,
const locale&)'
/home/fdt/dev/gcc/build_versioned_ns/x86_64
On 16/11/22 12:54, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
On 15/11/22 17:17, Jonathan Wakely wrote:
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough. Whe
On 15/11/22 17:17, Jonathan Wakely wrote:
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything proper
Any chance to review this one ?
On 06/10/22 19:38, François Dumont wrote:
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.
This tim
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]
libstdc++-v3/ChangeLog:
PR libstdc++/107189
*
libstdc++: Remove _Alloc_node instance in _Rb_tree [PR107189]
libstdc++-v3/ChangeLog:
PR libstdc++/107189
* include/bits/stl_tree.h
(_Rb_tree<>::_M_insert_range_equal): Remove
unused _Alloc_node instance.
Ok to commit ?
François
diff --git a/libstd
Hi
Now that pretty printer is fixed (once patch validated) I'd like to
propose this patch again.
Note that I'am adding a check on pretty printer with a std::any on
a std::wstring. I did so because of the FIXME in printers.py which is
dealing with 'std::string' explicitely. Looks like
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.
This time I think the problem was in those lines:
if self.type_obj == t
On 01/10/22 17:30, Jonathan Wakely wrote:
On Sat, 1 Oct 2022 at 11:43, François Dumont wrote:
On 01/10/22 12:06, Jonathan Wakely wrote:
On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++
wrote:
I had forgotten to re-run tests after I removed the #define
_GLIBCXX_USE_CXX11_ABI 0.
The
On 01/10/22 12:06, Jonathan Wakely wrote:
On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++
wrote:
I had forgotten to re-run tests after I removed the #define
_GLIBCXX_USE_CXX11_ABI 0.
The comment was misleading, it could also impact output of std::list.
I am also restoring the corre
I had forgotten to re-run tests after I removed the #define
_GLIBCXX_USE_CXX11_ABI 0.
The comment was misleading, it could also impact output of std::list.
I am also restoring the correct std::string alias for
std::__cxx11::basic_string, even if with my workaround it doesn't really
matter as
Sometimes substitution of basic_string by one of the std::string
typeedef fails. Here is the fix.
libstdc++: Fix gdb pretty printers when dealing with std::string
Since revision 33b43b0d8cd2de722d177ef823930500948a7487 std::string
and other
similar typedef are ambiguous from a gdb
Hi
This patch fix failures when _GLIBCXX_INLINE_VERSION mode and running:
make check-debug RUNTESTFLAGS=prettyprinters.exp
libstdc++: [_GLIBCXX_INLINE_VERSION] Add gdb pretty print for
_GLIBCXX_DEBUG
In _GLIBCXX_DEBUG mode containers are in std::__debug namespace but
not templat
I stopped my research to find out if those types ever existed in 2001.
Clearly they do not exist now.
libstdc++: Remove useless gdb printer registrations.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Remove printer
registration for non-existing
ty
libstdc++: [_GLIBCXX_INLINE_VERSION] Fix test dg-prune-output
libstdc++-v3/ChangeLog:
*
testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc: Adapt
dg-prune-output to
_GLIBCXX_INLINE_VERSION mode.
With this patch all tests are Ok in _GLIBCXX_INLINE_V
libstdc++: [_GLIBCXX_INLINE_VERSION] Cleanup
gnu-versioned-namespace.ver
Remove expressions for symbols in std::__detail::__8 namespace,
they are obsolete since
version namespace applies only at std:: level, not at sub-levels.
libstdc++-v3/ChangeLog:
* config/abi/
On 05/09/22 20:30, Will Hawkins wrote:
Based on Jonathan's work, here is a patch for the implementation of operator+
on std::string that makes sure we always use the best allocation strategy.
I have attempted to learn from all the feedback that I got on a previous
submission -- I hope I did the
libstdc++: glibc mallinfo deprecated, use mallinfo2 when version =>
2.33
glibc mallinfo is now deprecated resulting in make check-performance
failure. When glibc => 2.33 prefer mallinfo2.
libstdcxx-v3/ChangeLog:
* testsuite/util/testsuite_performance.h
(__gnu_test:
libstdc++: Use glibc >= 2.33 mallinfo2 function
mallinfo started to be deprecated which makes performance tests failed
to build, just
adopt mallinfo2.
libstdcxx-v3/ChangeLog:
* testsuite/util/testsuite_performance.h (__mallinfo): New, our
own mallinfo
struct with just what we
Any feedback regarding this proposal:
https://gcc.gnu.org/pipermail/libstdc++/2021-June/052821.html
On 23/06/21 22:34, François Dumont wrote:
Hi
Following the message to propose an alternative lower_bound and the
reply to use three way comparison I try to implement this.
Before going furthe
On 31/08/22 12:11, Jonathan Wakely wrote:
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBC
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
generation on
_GLIBCXX_DEBUG assertions. Prerequi
If I got your point correctly here is this patch again with just the
change on '0' becoming 'nullptr' in assertions.
libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
Review null string checks to show:
_String != nullptr
rather than:
_String != 0
libstdc
Following my remark about tests XFAIL-ing when running 'make check' I'd
like to propose this to avoid this situation.
libstdc++: [_GLIBCXX_ASSERTIONS] Activate basic
_GLIBCXX_DEBUB_PEDANTIC checks
Activate __glibcxx_requires_string/__glibcxx_requires_string_len in
basic _GLIBCXX_ASSE
With the patch !
On 14/08/22 17:32, François Dumont wrote:
I think we can add those checks.
Note that I wonder if it was needed as in basic_string_view I see
usages of __attribute__((__nonnull__)). But running the test I saw no
impact even after I try to apply this attribute to the
starts_wi
I think we can add those checks.
Note that I wonder if it was needed as in basic_string_view I see usages
of __attribute__((__nonnull__)). But running the test I saw no impact
even after I try to apply this attribute to the starts_with/ends_with
methods themselves.
Also note that several che
1 - 100 of 284 matches
Mail list logo
