Tested x86_64-linux. Pushe to trunk.
-- >8 --
This implements that changes from P1132R8, including optimized paths for
std::shared_ptr and std::unique_ptr.
For std::shared_ptr we pre-allocate a new control block in the
std::out_ptr_t constructor so that the destructor is non-throwing. This
requi
From: Thomas Rodgers
Tested x86_64-linux, testing underway on powerpc-aix and sparc-solaris.
-- >8 --
This change splits the __wait_args data members to a new struct
__wait_args_base and then passes that type by const pointer to the low
level implementation functions.
libstdc++-v3/ChangeLog:
From: Thomas Rodgers
These two patches were written by Tom earlier this year, before he left
Red Hat. We should finish reviewing them for GCC 14 (and probably squash
them into one?)
Tom, you mentioned further work that changes the __platform_wait_t* to
uintptr_t, is that ready, or likely to be r
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The formatter for std::thread::id should default to right-align, and the
formatter for std::stacktrace_entry should not just ignore the
fill-and-align and width from the format-spec!
libstdc++-v3/ChangeLog:
PR libstdc++/112564
* inc
On Thu, 16 Nov 2023 at 13:49, Jonathan Wakely wrote:
>
> From: Thomas Rodgers
>
> These two patches were written by Tom earlier this year, before he left
> Red Hat. We should finish reviewing them for GCC 14 (and probably squash
> them into one?)
>
> Tom, you mentioned f
On Fri, 17 Nov 2023 at 04:44, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely
> > Date: Thu, 16 Nov 2023 08:12:39 +
>
> > PR libstdc++/111667
> > * include/Makefile.am: Add new header.
> > * include/Makefile.in: Regenerate.
> >
On Fri, 17 Nov 2023 at 01:34, Cassio Neri wrote:
>
> The following functions invoke signed integer overflow (UB) for some extreme
> values of days and months [1]:
>
> weekday operator+(const weekday& x, const days& y); // #1
> month operator+(const month& x, const months& y); // #2
>
> For #1
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h: Fix Doxygen markup.
---
libstdc++-v3/include/bits/chrono_io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/chrono_io.h
b/libstdc++-v3/include/bits/chrono_io.h
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Improve Doxygen comments for std::out_ptr etc. and add a test for the
feature test macro. Also remove a redundant preprocessor condition.
Ideally the docs for std::out_ptr and std::inout_ptr would show examples
of how to use them and what they do,
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is more consistent with the specification in the standard.
libstdc++-v3/ChangeLog:
* include/std/utility (in_range): Rename _Up parameter to _Res.
---
libstdc++-v3/include/std/utility | 14 +++---
1 file changed, 7 insertions(
Tested x86_64-linux. Pushed to trunk.
GCC generates better code for add_sat if we use:
unsigned z = x + y;
z |= -(z < x);
return z;
If the compiler can't be improved we should consider using that instead
of __builtin_add_overflow.
-- >8 --
This was approved for C++26 last week at the WG21 me
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* config.h.in: Regenerate.
---
libstdc++-v3/config.h.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index c0aa51af3f0..17da7bb9867 100644
--- a/libstdc++-v3/conf
This needs tests, and doesn't include the changes to the standard
containers to add insert_range etc. (but they work with ranges::to
anyway, using the existing member functions).
I plan to write the tests and push this tomorrow.
I've trimmed the boring bits of the version.h changes, that are caus
I'll probably push this before stage 1 closes.
I might move the new lambda out to a struct at namespace scope first
though.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/110801
* include/std/format (_Sink_iter::_M_get_pointer)
(_Sink_iter::_M_end_pointer): New functions
There's a TODO here about checking for invalid UTF-8, which is done by
the next patch.
I don't know if the Windows code actually works. I tried to test it with
mingw and Wine, but I got garbled text. But I'm not sure if that's my
code here, or the conversion to UTF-16, or how I'm testing, or just
This is a naive implementation of the UTF-8 validation algorithm, which
could definitely be optimized. But it's faster than using
std::codecvt_utf8 and checking the result of that, which is the only
existing code we have to do it in the library.
As the TODO suggests, we could do the UTF-8 to UTF-1
On Fri, 17 Nov 2023 at 17:01, Daniel Krügler wrote:
>
> Am Fr., 17. Nov. 2023 um 16:32 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux. Pushed to trunk.
> >
> > GCC generates better code for add_sat if we use:
> >
> > unsigned z = x + y
On Fri, 17 Nov 2023 at 15:32, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> GCC generates better code for add_sat if we use:
>
> unsigned z = x + y;
> z |= -(z < x);
> return z;
>
> If the compiler can't be improved we s
Hi,
Libstdc++ patches need to be CC'd to the gcc-patches list as well.
On Wed, 8 Nov 2023 at 10:26, Peng Fan wrote:
>
> libstdc++-v3:
>
> * configure.host: Add abi_baseline_pair for LoongArch.
> * config/abi/post/riscv64-linux-gnu: New directory.
> * config/abi/post/riscv64-linux-gnu
Here's an improved version of this patch, which I've pushed to trunk.
Testeed x86_64-linux.
-- >8 --
This optimizes the simple case of formatting a single string, integer
or bool, with no format-specifier (so no padding, alignment, alternate
form etc.)
libstdc++-v3/ChangeLog:
PR libstd
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 needed too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/112607
* include/std/format (basic_format_arg::_S_to_arg_type): Check
value_type for basic_string_view and basic_string
specializations.
* te
On Mon, 20 Nov 2023 at 02:13, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely
> > Date: Thu, 16 Nov 2023 17:20:09 +
>
> > PR libstdc++/112564
> > * include/std/stacktrace (formatter::format): Format according
> > to format-
On Sun, 19 Nov 2023 at 21:53, Jan Hubicka wrote:
>
> Hi,
> this patch speeds up the push_back at -O3 significantly by making the
> reallocation to be inlined by default. _M_realloc_insert is general
> insertion that takes iterator pointing to location where the value
> should be inserted. As suc
Pushed to wwwdocs.
---
htdocs/gcc-14/changes.html | 7 +++
1 file changed, 7 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index e5d3970c..7278f753 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -138,12 +138,16 @@ a work-in-pr
- archived on a daily basis on
> the http://www.w3.org/1999/xlink";
> xlink:href="http://gcc.gnu.org/ml/gcc-testresults/current";>gcc-testresults
Good point. I'll push the attached patch to the docs.
commit fd7a339512b60545700124b21700fb86a6527f76
Author: Jonat
On Mon, 20 Nov 2023 at 15:44, Jan Hubicka wrote:
>
> > > + // RAII type to destroy initialized elements.
> >
> > There's only one initialized element, not "elements".
> >
> > > + struct _Guard_elts
> > > + {
> > > + pointer _M_first, _M_last; // Elements
On Mon, 20 Nov 2023 at 16:18, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely
> > Date: Mon, 20 Nov 2023 11:55:22 +
>
> > The changelog entry does say "Change compile test to run."
>
> Wow, it's right there. The doh:est of doh:s on me. So
On Tue, 21 Nov 2023 at 12:50, Jan Hubicka wrote:
>
> > > + // RAII type to destroy initialized elements.
> >
> > There's only one initialized element, not "elements".
> >
> > > + struct _Guard_elts
> > > + {
> > > + pointer _M_first, _M_last; // Elements
Tested x86_64-linux. Pushed to trunk. Backports to follow.
-- >8 --
libstdc++-v3/ChangeLog:
* include/tr2/dynamic_bitset (dynamic_bitset): Pass zero and one
characters to _M_copy_from_string.
* testsuite/tr2/dynamic_bitset/string.cc: New test.
---
libstdc++-v3/include/tr
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Also define the new feature test macros from P2833R2, indicating that
std::span and std::expected are supported for freestanding mode.
libstdc++-v3/ChangeLog:
* include/bits/version.def (freestanding_expected): New macro.
(span): Ad
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This C++26 change makes several classes "partially freestanding", but we
already fully supported them in freestanding mode. All we need to do is
define the new feature test macros and add tests for them.
libstdc++-v3/ChangeLog:
* include/bi
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This was recently approved for C++26.
We should define the __cpp_lib_freestanding_cstring macro in
as well as , but we do not currently install our own
for most targets.
libstdc++-v3/ChangeLog:
* include/bits/version.def (freestanding_cs
On Tue, 21 Nov 2023 at 16:24, Jan Hubicka wrote:
>
> Hi,
> this patch turns memmove to memcpy where we can and also avoids extra
> guard checking if block is non-empty. This does not show as performance
> improvement in my push_back micro-benchmark because vector rellocation
> does not happen tha
On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I
> push this?
The library parts are OK.
The variable template is_trivially_copyable_v just uses
__is_trivially_copyable so should be just as efficient, and the change
On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote:
>
> On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
> >
> > Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I
> > push this?
>
> The library parts are OK.
>
> The variable templa
Jakub noted in the PR that this test fails for -std=c++98.
Tested x86_64-linux.
OK for trunk?
-- >8 --
The _M_realloc_insert member does not have the trivial relocation
optimization for C++98, which seems to be why the _M_end_of_storage
member does not get optimized away. Make this test unsuppo
On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
>
> > > On Sunday, 19 November 2023 22:53:37 CET Jan Hubicka wrote:
> > > > Sadly it is really hard to work out this
> > > > from IPA passes, since we basically care whether the iterator points to
> > > > the same place as the end pointer, which are
On Thu, 23 Nov 2023 at 15:44, Jan Hubicka wrote:
>
> Hi,
> so if I understand it right, it should be safe to simply replace memmove
> by memcpy. I wonder if we can get rid of the count != 0 check at least
> for glibc systems.
I don't think we can do that. It's still undefined with glibc, and
gli
On Tue, 21 Nov 2023 at 18:11, Marc Glisse wrote:
>
> On Tue, 21 Nov 2023, Jonathan Wakely wrote:
>
> > CC Marc Glisse who added the relocation support. He might recall why
> > we use memmove when all uses are for newly-allocated storage, which
> > cannot overlap the
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The operator== function is only a friend of the LHS argument, so cannot
access the private member of the RHS argument. Use the public accessor
instead.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_allocator.h (uneq_allocator): Fix
Here's the finished version of the std::ranges::to patch, which I've
pushed to trunk.
Tested x86_64-linux.
-- >8 --
This adds the std::ranges::to functions for C++23. The rest of P1206R7
is not yet implemented, i.e. the new constructors taking the
std::from_range tag, and the new insert_range, a
On Fri, 24 Nov 2023 at 20:07, Jan Hubicka wrote:
> The vector.tcc change was regtested on x86_64-linux, OK?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/vector.tcc (reserve): Copy _M_start and _M_finish
> to local variables to allow propagation across call to
> allocator.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h: Fix typo in comment.
---
libstdc++-v3/include/bits/stl_uninitialized.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/stl_uninitializ
Tested x86_64-linux. Pushed to trunk. Backports to follow.
-- >8 --
This is needed in order to compile it as a header-unit, which might be
desired because it's included by both and .
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h: Include .
---
libstdc++-v3/include/bits/atomic_w
On Wed, 20 Sept 2023 at 05:51, François Dumont via Libstdc++
wrote:
>
> libstdc++: Remove std::constract_violation from versioned namespace
Spelling mistake in contract_violation, and it's not
std::contract_violation, it's std::experimental::contract_violation
>
> GCC expects this type to be in
On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Now that bootstrap has finished, I have gotten regressions in the
> following libstdc++ tests:
>
> Running libstdc++:libstdc++-dg/conformance.exp ...
> FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++23
On Sat, 23 Sept 2023, 08:30 Nathaniel Shead,
wrote:
> On Sat, Sep 23, 2023 at 07:40:48AM +0100, Jonathan Wakely wrote:
> > On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
> > libstd...@gcc.gnu.org> wrote:
> >
> > > Now that bootstrap has finish
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward_list): Define for C++23.
* include/bits/version.def (forward_like): Define.
* include/bits/version.h: Regenerate.
* include/std/utility (__glibcxx_want_forward_li
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As noted in PR c++/111512, GCC does ADL for __builtin_memcpy if it is
unqualified, which can cause errors for template argument types which
cannot be completed.
Casting the memcpy arguments to void* prevents ADL from considering the
problem type.
l
This is the fix for the release branches, where std::to_array is
implemented differently.
Tested x86_64-linux. Pushed to gcc-13 and gcc-12. Will push to gcc-11
after testing.
-- >8 --
Qualify the calls to the __to_array helper to prevent ADL, so we don't
try to complete associated classes.
libs
On Sat, 23 Sept 2023 at 08:30, Nathaniel Shead via Libstdc++
wrote:
>
> On Sat, Sep 23, 2023 at 07:40:48AM +0100, Jonathan Wakely wrote:
> > On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
> > libstd...@gcc.gnu.org> wrote:
> >
> > > Now tha
On Wed, 27 Sept 2023 at 16:37, Tom Tromey wrote:
>
> >>>>> Jonathan Wakely via Gcc-patches writes:
>
> Replying to a quite old email...
>
> I ran a Python linter on the libstdc++ pretty-printers.
>
> I have fixes for most of the issues that are worth fixi
On Wed, 27 Sept 2023, 18:25 Tom Tromey via Libstdc++,
wrote:
> >> I have fixes for most of the issues that are worth fixing (I didn't
> >> bother with line lengths -- FWIW in gdb we just run 'black' and don't
> >> worry about these details),
>
> Jonathan> I used autopep8 and committed the result
On Wed, 27 Sept 2023 at 20:57, Jonathan Wakely
wrote:
>
>
>
> On Wed, 27 Sept 2023, 18:25 Tom Tromey via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>>
>> >> I have fixes for most of the issues that are worth fixing (I didn't
>> >> bother wit
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 we still have C pointers is at the
> iterator::pointer level but it's consistent with std::list
> implementation and also logical considering tha
On Thu, 27 Jun 2024, 01:53 Matthias Kretz, wrote:
> Ah, thank you. I didn't realize that there's a default for dg-do. I
> probably
> knew it back when I added check_vect_support_and_set_flags...
>
> OK for all branches from my side.
>
Yup, ok to push then, thanks.
> -Matthias
>
> On Wednesday
On Thu, 27 Jun 2024, 05:05 Eric Gallager, wrote:
> On Wed, Jun 26, 2024 at 4:28 PM Jonathan Wakely
> wrote:
> >
> > Pushed to trunk. We have nearly a year to make improvements to it
> > before it's needed for the gcc-15 branch ... I just hope I remember
The previous commit allows these to work for constexpr too, which is
nice.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This adds debug assertions for std::vector element access.
libstdc++-v3/ChangeLog:
PR libstdc++/103191
* include/bits/stl_bvector.h (vector::operator[])
Tested x86_64-linux. Pushed to trunk.
Worth backporting, I think, but I'll wait a bit.
-- >8 --
Some of our debug assertions expand to nothing unless
_GLIBCXX_ASSERTIONS is defined, which means they are not checked during
constant evaluation. By making them unconditionally expand to a
__glibcxx_
Tested x86_64-linux. Pushed to trunk. Backports needed to 13 and 14.
-- >8 --
Using std::chrono::abs is only valid if numeric_limits::is_signed
is true, so using it unconditionally made it ill-formed to format a
duration with an unsigned rep.
The duration formatter might as negate the duration i
I'm planning to push this, although arguably the first change isn't
worth doing if we can't use it everywhere. If we need to keep the old
code for EDG, maybe we should just keep using that? The new version
probably compiles faster though.
Removing the dependency on std::aligned_storage and adding
As I commented in the PR, I think it would be nice if the compiler
accepted C++11 alignof in C++98 mode when -faligned-new is used. But
even if G++ added that, we'd need Clang to use it, and then wait a few
releases for that new Clang support to be in widespread use.
So let's just disable the exte
This refactoring to use RAII doesn't seem to make any difference in
benchmarks, although the generated code for some std::vector operations
seems to be slightly larger. Maybe it will be faster (or slower) in some
cases I didn't test?
I think I like the change anyway - any other opinions on whether
For trivial types std::__uninitialized_default (which is used by
std::uninitialized_value_construct) value-initializes the first element
then copies that to the rest of the range using std::fill.
Tamar is working on improved vectorization for std::fill, but for this
value-initialized case where we
By generalizing std::__uninitialized_default to work with non-common
ranges (i.e. iterator/sentinel pair) we can reuse it for the
ranges::uninitialized_value_construct function. Doing that ensures that
whatever optimizations we have for std::uninitialized_value_construct
are automatically used for
Here's what I've pushed, with a typo fixed as spotted by Kristian in the
PR comments.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For the GNU locale model, codecvt::do_out and codecvt::do_in incorrectly
return 'ok' when the destination range is empty. That happens because
detecting incomplete
On Thu, 27 Jun 2024 at 11:53, Jonathan Wakely wrote:
>
> For trivial types std::__uninitialized_default (which is used by
> std::uninitialized_value_construct) value-initializes the first element
> then copies that to the rest of the range using std::fill.
>
> Tamar is w
On Thu, 27 Jun 2024 at 13:40, Maciej Cencora wrote:
>
> Hi,
>
> not sure whether I've missed some conditional that would exclude this case,
> but your change seems to incorrectly handle trivial types that have a
> non-zero bit pattern of value-initialized object, e.g. pointer to member.
Good poi
On Thu, 27 Jun 2024 at 13:49, Jonathan Wakely wrote:
>
> On Thu, 27 Jun 2024 at 13:40, Maciej Cencora wrote:
> >
> > Hi,
> >
> > not sure whether I've missed some conditional that would exclude this case,
> > but your change seems to incorrectly handle tr
to the pointer
type.
Your _S_case function is wrong though: you can't construct the fancy
pointer type from a raw pointer. You need to use
pointer_traits<__node_ptr>::pointer_to(*rawptr).
>
> François
>
> On 26/06/2024 23:41, Jonathan Wakely wrote:
> > On Wed, 2
On Thu, 27 Jun 2024 at 14:27, Maciej Cencora wrote:
>
> I think going the bit_cast way would be the best because it enables the
> optimization for many more classes including common wrappers like optional,
> variant, pair, tuple and std::array.
This isn't tested but seems to work on simple case
troduce in C++ language a new
> compiler-backed type trait like:
> std::zero_initialized_object_has_all_zeros_object_representation.
Yes, I think a new built-in is the only approach that will work for
class types. I'll just limit the optimization to scalars (excluding
member pointers).
>
Pushed to trunk.
On Thu, 27 Jun 2024 at 10:03, Jonathan Wakely wrote:
>
> I'm planning to push this, although arguably the first change isn't
> worth doing if we can't use it everywhere. If we need to keep the old
> code for EDG, maybe we should just keep using that?
Pushed to trunk.
On Thu, 27 Jun 2024 at 10:01, Jonathan Wakely wrote:
>
> As I commented in the PR, I think it would be nice if the compiler
> accepted C++11 alignof in C++98 mode when -faligned-new is used. But
> even if G++ added that, we'd need Clang to use it, and then wait
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We optimize std::equal to memcmp for integers and pointers, which means
that std::byte comparisons generate bigger code than char comparisons.
We can't use memcmp for arbitrary enum types, because they could have an
overloaded operator== that has cu
Tested x86_64-linux. Pushed to trunk. Backports needed.
-- >8 --
When the library is configured with --disable-libstdcxx-verbose the
assertions just abort instead of calling __glibcxx_assert_fail, and so I
didn't export that function for the non-verbose build. However, that
option is documented t
On Wed, 3 Jul 2024 at 15:37, Jakub Jelinek wrote:
>
> Hi!
>
> With the PR115754 fix in, constexpr placement new mostly just works,
> so this patch just adds constexpr keyword to the placement new operators
> in , adds FTMs and testsuite coverage.
>
> There is one accepts-invalid though, the
> new
On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote:
>
> This refactoring to use RAII doesn't seem to make any difference in
> benchmarks, although the generated code for some std::vector operations
> seems to be slightly larger. Maybe it will be faster (or slower) in some
>
On Wed, 3 Jul 2024 at 16:51, Jakub Jelinek wrote:
>
> On Wed, Jul 03, 2024 at 11:41:58AM -0400, Jason Merrill wrote:
> > On 7/3/24 10:37 AM, Jakub Jelinek wrote:
> > > +#if __cpp_lib_constexpr_new >= 202406L
> > > +# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr
> > > +#else
> > > +# define _GLIBCX
Tested x86_64-linux. Pushed to trunk.
Patch v3 adds the in-range check to ranges::find to avoid false positive
matches:
if (static_cast>(__value) != __value)
return __last;
-- >8 --
This optimizes std::find to use memchr when searching for an integer in
a range of bytes.
libstdc++-v3/Cha
Thanks for the feedback - pushed.
On Wed, 3 Jul 2024 at 16:37, Ville Voutilainen
wrote:
>
> On Wed, 3 Jul 2024 at 18:33, Jonathan Wakely wrote:
> >
> > On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote:
> > >
> > > This refactoring to use RAII do
These errors only show up when testing with -std=c++26 which isn't done
by default.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Since r15-1794-gbeb7a418aaef2e the -Wdelete-incomplete diagnostic is a
permerror instead of a (suppressed in system headers) warning. Add
dg-error directives.
libst
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The r15-1857 change means that is included by for
C++17 and up, which breaks code including inside an extern "C"
block. Although doing that is not allowed by the C++ standard, there's
lots of existing code which incorrectly thinks it's a good idea
This one needs to be backported too.
On Sat, 6 Jul 2024 at 21:18, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> We should not use [[unlikely]] before C++20, so use [[__unlikely__]]
> instead.
>
> libstdc++-v3/ChangeLog:
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We should not use [[unlikely]] before C++20, so use [[__unlikely__]]
instead.
libstdc++-v3/ChangeLog:
* include/std/variant (_Variant_storage::_M_reset): Use
__unlikely__ form of attribute instead of unlikely.
---
libstdc++-v3/incl
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We have several nearly identical tests under 17_intro/headers which only
differ in a -std option set using dg-options. Since the testsuite now
supports running tests with multiple -std options (and I test that
regularly) we don't need these duplicate
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The memchr optimization introduced in r15-1857 needs to advance the
start iterator instead of returning the sentinel.
libstdc++-v3/ChangeLog:
PR libstdc++/115799
* include/bits/ranges_util.h (__find_fn): Return iterator
inst
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The r15-1857 change didn't correctly restrict the new optimization to
contiguous iterators.
libstdc++-v3/ChangeLog:
PR libstdc++/115799
* include/bits/stl_algo.h (find): Use 'if constexpr' so that
memchr optimization is a di
Tested x86_64-linux. Pushed to trunk. This should be backported too.
-- >8 --
The definition of the _Atomic(T) macro needs to refer to ::std::atomic,
not some other std::atomic relative to the current namespace.
libstdc++-v3/ChangeLog:
PR libstdc++/115807
* include/c_compatibili
This fixes another problem with my recent changes to use memchr in
std::find.
Tested x86_64-linux.
-- >8 --
For an integer-class type we need to use an explicit conversion to size_t.
libstdc++-v3/ChangeLog:
PR libstdc++/115799
* include/bits/ranges_util.h (__find_fn): Make conv
Pushed to trunk.
On Mon, 8 Jul 2024 at 20:44, Jonathan Wakely wrote:
>
> This fixes another problem with my recent changes to use memchr in
> std::find.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> For an integer-class type we need to use an explicit conversion to size
Tested x86_64-linux. Pushed to trunk. Backports could follow.
-- >8 --
The consensus in the standard committee is that this change shouldn't be
necessary, and the Allocator requirements should require conversions
between rebound allocators to be implicit. But we can make it work for
now anyway.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For the C locale we know the encoding is ASCII, so we can avoid using
newlocale and nl_langinfo_l. Similarly, for an unnamed locale, we aren't
going to get a useful answer, so we can just use a default-constrcuted
std::text_encoding representing an u
Tested x86_64-linux. Pushed to trunk. Probably a good idea to backport
it to 13 and 14, for consistency.
-- >8 --
Users are not supposed to create objects of this type, and there's no
reason it needs to be copyable. LWG 4061 makes it non-copyable and
non-default constructible.
libstdc++-v3/Chang
On Thu, 11 Jul 2024 at 14:23, Alexandre Oliva wrote:
>
>
> Passing an arbitrary error number to strerror* functions doesn't seem
> to be portable; 19_diagnostics/system_error/cons-1.cc is hitting
> runtime errors in the block that attempts to instantiate a
> std:;system_error for error number 95.
On Thu, 11 Jul 2024 at 14:22, Alexandre Oliva wrote:
>
>
> On a target that doesn't enable decimal float components in libgcc
> (because the libc doens't define all required FE_* macros), but whose
> compiler supports _Decimal* types, the effective target requirement
> dfp passes, but several test
On Thu, 11 Jul 2024 at 15:28, Jonathan Wakely wrote:
>
> On Thu, 11 Jul 2024 at 14:22, Alexandre Oliva wrote:
> >
> >
> > On a target that doesn't enable decimal float components in libgcc
> > (because the libc doens't define all required FE_* macros),
On Thu, 11 Jul 2024 at 14:21, Alexandre Oliva wrote:
>
>
> Having observed failures of these two tests on yet another aarch64
> operating system, and having concluded that the conditions that
> trigger the problem ought to be present on all aarch64 targets, I'm
> now matching any aarch64 target_os
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test uses -fkeep-inline-functions and with debug mode enabled that
compiles much slower and times out if the system is under heavy load.
The original problem being tested is independent of debug mode, so just
require normal mode for the test.
On Thu, 11 Jul 2024 at 17:23, Alexandre Oliva wrote:
>
> On Jul 11, 2024, Jonathan Wakely wrote:
>
> > And std::system_error doesn't limit the values that can be passed to
> > it either. So I'd prefer to keep testing with arbitrary int values,
> > becaus
801 - 900 of 10092 matches
Mail list logo
