On Thu, 23 May 2024 at 00:06, Lebrun-Grandie, Damien wrote:
>
> See patch attached to this email.
Thanks for the patch. Sorry it took a while, but I've now pushed it to
trunk, along with the test below.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The previous commit changed atomic_ref to not
I sent v1 of this patch in February, and it added the new symbols to
libstdc++exp.a which meant users needed to use -lstdc++exp to format
chrono types in C++23 mode. That was less than ideal.
This v2 patch adds the new symbols to the main library, which means no
extra step to get the new features,
On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva wrote:
>
> On Jul 11, 2024, Jonathan Wakely wrote:
>
> > There's no requirement that system_error uses strerror, that's just an
> > implementation detail.
>
> *nod*. I meant it was more of a libc test in the c
On Fri, 12 Jul 2024 at 10:27, Jonathan Wakely wrote:
>
> On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva wrote:
> >
> > On Jul 11, 2024, Jonathan Wakely wrote:
> >
> > > There's no requirement that system_error uses strerror, that's just an
> > &g
Tested x86_64-linux.
-- >8 --
We already enable this for -std=gnu++20 but we can do it for -std=c++20
too. Both libc++ and MSVC also treat this change as a DR for C++20.
Now that the previous change to the value of __cpp_lib_format is
supported, we can finally update it to 202304 to indicate sup
Tested x86_64-linux.
-- >8 --
Implement the std::variant changes from P2637R3.
libstdc++-v3/ChangeLog:
PR libstdc++/110356
* include/bits/version.def (variant): Update for C++26.
* include/bits/version.h: Regenerate.
* include/std/variant (variant::visit): New me
On Fri, 12 Jul 2024 at 00:23, I wrote:
>
> I sent v1 of this patch in February, and it added the new symbols to
> libstdc++exp.a which meant users needed to use -lstdc++exp to format
> chrono types in C++23 mode. That was less than ideal.
>
> This v2 patch adds the new symbols to the main library,
Tested x86_64-linux.
-- >8 --
Implement the changes from P2757R3, which enhance the parse context to
be able to do type checking on format arguments, and to use that to
ensure that args used for width and precisions are integral types.
libstdc++-v3/ChangeLog:
PR libstdc++/115776
Tested x86_64-linux.
-- >8 --
Implement the std::format changes from P2637R3. This adds visit member
functions to std::basic_format_arg and deprecates the non-member
function std::visit_format_arg.
libstdc++-v3/ChangeLog:
PR libstdc++/110356
* include/bits/c++config (_GLIBCXX26_
Tested x86_64-linux.
-- >8 --
We already supported this feature, but couldn't set the feature test
macro accordingly because we were missing support for older features.
Now that we support all the older changes, we can set this to
the correct value.
libstdc++-v3/ChangeLog:
* include/bi
I have some follow-up patches which are enabled by this, so that other
algos which use std::__find_if can benefit from the memchr optimizations
recently added to std::find. Currently, they can't benefit because they
use the internal __find_if and only std::find is optimized.
Tested x86_64-linux. I
On Tue, 16 Jul 2024 at 13:05, Jonathan Wakely wrote:
>
> On Fri, 12 Jul 2024 at 00:23, I wrote:
> >
> > I sent v1 of this patch in February, and it added the new symbols to
> > libstdc++exp.a which meant users needed to use -lstdc++exp to format
> > chrono types in
On Tue, 16 Jul 2024 at 13:34, Jonathan Wakely wrote:
>
> On Tue, 16 Jul 2024 at 13:05, Jonathan Wakely wrote:
> >
> > On Fri, 12 Jul 2024 at 00:23, I wrote:
> > >
> > > I sent v1 of this patch in February, and it added the new symbols to
> > > l
Tested x86_64-linux. Pushed to trunk, gcc14 and gcc-13.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/115063
* include/std/stacktrace (basic_stacktrace::max_size): Fix typo
in reference to _M_alloc member.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Check
Pushed to trunk.
-- >8 --
This section can be misread to say that shrink_to_fit is available from
GCC 3.4, but it was added later.
libstdc++-v3/ChangeLog:
* doc/xml/manual/strings.xml: Clarify that GCC 4.5 added
std::string::shrink_to_fit.
* doc/html/manual/strings.html:
Tested x86_64-linux, x86_64-w64-mingw32. Pushed to trunk. Backport to
gcc-14 to follow.
-- >8 --
Do not use dynamic_cast unconditionally, in case libstdc++ is built with
-fno-rtti.
libstdc++-v3/ChangeLog:
PR libstdc++/115015
* src/c++23/print.cc (__open_terminal(streambuf*)) [!_
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Prior to C++20 this enum type doesn't have a fixed underlying type,
which means it can be modified by -fshort-enums, which then means the
HLE bits are outside the range of valid values for the type.
As it has a fixed type of int in C++20 and later,
On Tue, 7 May 2024 at 14:51, Ville Voutilainen
wrote:
>
> On Tue, 7 May 2024 at 16:47, Jonathan Wakely wrote:
> >
> > I don't think using a macro for these really saves us much, we can do
> > this to avoid duplication instead. And now it's not a big, multi-li
Pushed to trunk.
On Tue, 7 May 2024 at 15:04, Jonathan Wakely wrote:
>
> Tested x86_64-linux. This seems "obviously correct", and I'd like to
> push it. The current code definitely has a data race, i.e. undefined
> behaviour.
>
> -- >8 --
>
> The lazy c
On Thu, 16 May 2024 at 19:52, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> libstdc++-v3/Changelog
>
> * acinclude.m4 (GLIBCXX_ENABLE_BACKTACE): Add check for
> tlhelp32.h, matching libbacktrace.
> * configure: Regenerate.
> * config.h.in: Regenerate.
This
Tested x86_64-linux. Pushed to trunk, gcc-14 backport to follow.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/115119
* include/bits/unicode.h (_Iterator::operator++(int)): Fix typo
in increment expression.
* testsuite/ext/unicode/grapheme_view.cc: Check post-incr
Does anybody see any issue with the drive-by fixes to constraint
std::formatter to only work for pointers and integers (since
we don't know how to format pthread_t if it's an arbitrary struct, for
example), and to cast pointers to const void* for output (because if
pthread_t is char* then writing i
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> I don't know if I picked the right way to do it.
>
> When acceptable I think the declaration should be moved into
> ops-common.h, since then we co
Tested x86_64-linux. Committed as obvious.
I'll backport it too.
-- >8 --
The correct dialect for std::to_address is cxx20 not cxx11.
gcc/cp/ChangeLog:
PR libstdc++/107800
* cxxapi-data.csv : Change dialect to cxx20.
* std-name-hint.gperf: Regenerate.
* std-name
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Ensure that the result of comparing the variant alternatives is
converted to bool immediately rather than copied.
libstdc++-v3/ChangeLog:
PR libstdc++/115145
* include/std/variant (operator==, operator!=, operator<)
(operato
Pushed to trunk. Backport to gcc-14 to follow.
On Fri, 17 May 2024 at 14:45, Jonathan Wakely wrote:
>
> Does anybody see any issue with the drive-by fixes to constraint
> std::formatter to only work for pointers and integers (since
> we don't know how to format pthread_t if
Tested x86_64-linux. Pushed to trunk. Backport needed too.
-- >8 --
Clang does not enable -fsized-deallocation by default, which means it
can't compile our and headers.
Make the __cpp_lib_generator macro depend on the compiler-defined
__cpp_sized_deallocation macro, and change to use unsized
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/locale_classes.h (locale::combine)
(locale::name, locale::operator==, locale::operator!=)
(locale::operator(), locale::classic): Add nodiscard
attribute.
* include/bits/l
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a bug in locale::combine where we fail to meet the standard's
requirement that the result is unnamed. It also implements two library
issues related to the names of combined locales (2295 and 3676).
libstdc++-v3/ChangeLog:
PR libs
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 usage of the _Guard type to other
parts of vect
It looks like my patch[1] to make b4 figure this out automagically won't
be accepted, so this makes it work for GCC. A similar commit could be
done for each project hosted on sourceware.org if desired.
[1]
https://lore.kernel.org/tools/20240523143752.385810-1-jwak...@redhat.com/T/#u
OK for trunk
On 24/05/24 13:56 -, Michael Levine (BLOOMBERG/ 731 LEX) wrote:
I've attached the v3 version of the patch as a single, squashed patch
containing all of the changes. I manually prepended my sign off to the patch.
Signed-off-by: Michael Levine
---
diff --git a/libstdc++-v3/include/bits/r
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/0
On Mon, 27 May 2024 at 09:26, Jakub Jelinek wrote:
>
> Hi!
>
> The r13-8207-g17acf9fbeb10d7adad commit changed some tests to use
> -lstdc++exp instead of -lstdc++_libbacktrace, but it didn't change
> the 19_diagnostics/stacktrace/hash.cc test, presumably because
> when it was added on the trunk, i
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:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' writing between 2 and 92233720368
-std=gnu++98 (test for excess errors)
>
> but it's already failing on master, my patch do not change anything.
Yes, that's been failing for ages.
>
> Tested under Linux x64,
>
> still ok to commit ?
>
> François
>
> On 24/05/2024 16:17, Jonathan Wakely wrote:
&
On Wed, 15 May 2024 at 20:50, Matthias Kretz wrote:
>
> Tested on aarch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu,
> x86_64-linux-gnu (-m64, -m32, -mx32), and arm-linux-gnueabi
>
> OK for trunk?
OK
> And when backporting, should I squash it with the commit that
> introduced the reg
On Tue, 28 May 2024 at 15:25, Rainer Orth wrote:
>
> Several of the 19_diagnostics/stacktrace tests FAIL on Solaris/SPARC (32
> and 64-bit), Solaris/x86 (32-bit only), and several other targets:
>
> FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
> FAIL: 19_diagnostics/stac
plification.
> (_M_range_initialize): Likewise and set _M_finish first
> from the result
> of __uninitialize_fill_n_a that can throw.
>
> Tested under Linux x86_64.
>
> Ok to commit ?
OK, thanks
>
> François
>
> On 28/05/2024 12:30, Jon
On Thu, 30 May 2024, 06:03 Alexandre Oliva, wrote:
>
> mkdir, chdir and chmod functions are defined in librtemscpu, that
> doesn't get linked in during libstdc++-v3 configure, but applications
> use -qrtems for linking, which brings those symbols in, so it makes
> sense to mark them as available
Thanks.
I got bounces from oarcorp.com and rtems.org, are the details in
MAINTAINERS out of date for Joel and Ralf?
On Thu, 30 May 2024 at 09:19, Alexandre Oliva wrote:
>
> On May 30, 2024, Jonathan Wakely wrote:
>
> > Typo here, "rtemps"?
>
> Ugh, thanks, fixed
t branch doesn't reallocate so the compiler doesn't think the
pointers can be invalidated.
> I'll look for a PR to associate, if you have one in mind do not hesitate
> to tell me.
It's discussed in PR 109849.
>
> François
>
>
> On 28/05/2024 12:28
On 31/05/24 11:07 -0300, Alexandre Oliva wrote:
A proprietary embedded operating system that uses clang as its primary
compiler ships headers that require __clang__ to be defined. Defining
that macro causes libstdc++ to adopt workarounds that work for clang
but that break for GCC.
So, introduc
On Sat, 1 Jun 2024 at 08:35, Olivier Hainque wrote:
>
>
>
> > On 31 May 2024, at 17:52, Alexandre Oliva wrote:
>
> >> Does the vxworks toolchain need to support the PSTL headers?
> >
> > Maybe we can do without them. I really don't know. Olivier?
>
> I have no indication that we can not-support
On Fri, 31 May 2024 at 16:52, Alexandre Oliva wrote:
>
> On May 31, 2024, Jonathan Wakely wrote:
>
> > On 31/05/24 11:07 -0300, Alexandre Oliva wrote:
> >> --- a/libstdc++-v3/include/pstl/pstl_config.h
> [...]
> >> -#if defined(__clang__)
> >> +#if
On Fri, 31 May 2024 at 18:43, Alexandre Oliva wrote:
>
> On May 31, 2024, Alexandre Oliva wrote:
>
> >> So either don't change this line at all, or just do a simple
> >> s/__clang__/_GLIBCXX_CLANG/
>
> > If c++config can be counted on, I'd be happy to do that, but I couldn't
> > tell that it coul
Pushed to trunk. I'll backport this, and link to the appropriate release
branch docs instead of the trunk docs.
-- >8 --
Link to the docs for GCC trunk instead. For the release branches, the
link should be to the docs for appropriate release branch.
Also replace the incomplete/outdated list of e
Here's an implementation of the C++26 header.
We should really have some tests that invoke GDB and check that the
breakpoint works when a debugger is attached. That seems tricky to do
via the main conformance.exp testsuite. It could be done via the
prettyprinters.exp testsuite, which already uses
We get smaller code at all optimization levels by not creating a
temporary object, just comparing lengths first and then using
traits_type::compare. This does less work than calling substr then
operator==.
libstdc++-v3/ChangeLog:
* include/std/string_view (starts_with(basic_string_view)):
The non-throwing allocation logic in std::stacktrace duplicates the
logic in , so we can just reuse those utilities.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Use __detail::__get_temporary_buffer.
(basic_stacktrace::_Impl::_M_
I'v refactored the code a bit, adding a new __get_temporary_buffer
helper, because I want to use that in in [PATCH 2/2].
I considered making __return_temporary_buffer also work for the
non-sized case, using non-sized delete if __len == 0, and then making
std::return_temporary_buffer call __return
Although it's only used from places where we are allocating a sensible
size, __detail::__get_temporary_buffer should really still check that
len * sizeof(T) doesn't wrap around to zero and allocate a buffer that's
smaller than expected.
This v2 patch is the same as v1 except for adding this check:
On Mon, 3 Jun 2024 at 14:36, Peter0x44 wrote:
> > +void
> > +std::breakpoint() noexcept
> > +{
> > +#if _GLIBCXX_HAVE_DEBUGAPI_H && defined(_WIN32) &&
> > !defined(__CYGWIN__)
> > + DebugBreak();
> > +#elif __has_builtin(__builtin_debugtrap)
> > + __builtin_debugtrap(); // Clang
> > +#elif define
Pushed to trunk.
On Sat, 1 Jun 2024 at 11:26, Jonathan Wakely wrote:
>
> We get smaller code at all optimization levels by not creating a
> temporary object, just comparing lengths first and then using
> traits_type::compare. This does less work than calling substr then
> operator
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/ChangeLog:
>
> PR libstdc++/109849
On Mon, 3 Jun 2024 at 18:46, François Dumont wrote:
>
>
> 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.
>
On Mon, 3 Jun 2024 at 16:31, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu (also -m32 and -mx32), aarch64-linux-gnu, and arm-
> linux-gnueabi(hf).
>
> OK for trunk and backports?
OK for all.
>
> --- 8< ---
>
> The special case for Clang in the trai
On Sat, 1 Jun 2024 at 12:23, Jonathan Wakely wrote:
>
> Although it's only used from places where we are allocating a sensible
> size, __detail::__get_temporary_buffer should really still check that
> len * sizeof(T) doesn't wrap around to zero and allocate a buffer that
On Sat, 1 Jun 2024 at 11:29, Jonathan Wakely wrote:
>
> The non-throwing allocation logic in std::stacktrace duplicates the
> logic in , so we can just reuse those utilities.
Pushed to trunk now.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/stacktrace (ba
Tested x86_64-linux. Pushed to trunk. Will backport to gcc-14 too.
-- >8 --
In r14-5689-g1fa85dcf656e2f I added std::span::at and made the correct
changes to the __cpp_lib_span macro (with tests for the correct value in
C++20/23/26). But I didn't make the declaration of std::span::at
actually dep
On Wed, 14 Aug 2024, 18:00 Hans-Peter Nilsson, wrote:
> (CC to the dejagnu project as a heads-up)
>
> Regtested cris-elf with a fresh newlib checkout where 2640
> libstdc++-v3 tests otherwise fail due to the stubbed newlib
> _getentropy. Ok to commit?
>
OK for trunk and release branches too if
On Wed, 14 Aug 2024, 16:01 Hans-Peter Nilsson, wrote:
> Regtested cris-elf, both an older newlib (FWIW: before the
> getentropy issue that I hoped to investigate before
> summer...maybe next summer) and a fresh checkout, both
> with/without --enable-newlib-iconv. I'm pleasantly
> surprised that
On Sun, 18 Aug 2024, 09:53 Gerald Pfeifer, wrote:
> When I updated one of the links yesterday I noticed we have this obsolete
> reference to GCC 4.0.1 and binutils 2.15.90.0.1.1 from 19 (nineteen) years
> ago.
>
> I suggest we remove these.
>
> Okay?
>
OK
> Gerald
>
>
> libstdc++-v3:
>
On Sun, 18 Aug 2024, 23:39 Eric Gallager, wrote:
> On Sun, Aug 18, 2024 at 4:52 AM Gerald Pfeifer wrote:
> >
> > When I updated one of the links yesterday I noticed we have this obsolete
> > reference to GCC 4.0.1 and binutils 2.15.90.0.1.1 from 19 (nineteen)
> years
> > ago.
> >
> > I suggest w
Hi,
It's not useful to CC the gcc-bugs list with patches. Please just send
the patch to the gcc-patches list (and any other appropriate lists,
like libstdc++ or fortran, if appropriate). If you want to update the
bugzilla report, you can manually add a comment to it with the URL of
the patch submi
On 05/08/24 09:32 +0200, Franciszek Witt wrote:
Hi, could someone review this patch?
This is built on top of the v2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232 the only
difference is fix for error59.C
I have tested it on x86_64 Ubuntu 22 machine.
Regards
Franciszek
---
Author:
On Mon, 19 Aug 2024 at 21:51, Gerald Pfeifer wrote:
>
> On Wed, 12 Oct 2022, Marek Polacek via Gcc-patches wrote:
> > +
> > +The two overload resolutions approach was complicated and quirky, so users
> > +should transition to the newer model. This change means that code that
> > +previously didn'
On Mon, 19 Aug 2024 at 22:34, Jonathan Wakely wrote:
>
> On Mon, 19 Aug 2024 at 21:51, Gerald Pfeifer wrote:
> >
> > On Wed, 12 Oct 2022, Marek Polacek via Gcc-patches wrote:
> > > +
> > > +The two overload resolutions approach was complicated and quirky, so
because it exposes an uninvestigated issue for one specific
> configuration, and a timeout at that.
>
> Alternatively (after analysis), the SOP is to put a derived
> minimal testcase in the *generic* parts of the test-suite (C
> or C++, as a runtime test) unless the compiled code reall
On Fri, 9 Aug 2024 at 10:29, Alex Coplan wrote:
>
> Together with the preparatory compiler patches, this patch restores
> unrolling in std::__find_if, but this time relying on the compiler to do
> it by using:
>
> #pragma GCC unroll 4
>
> which should restore the majority of the regression relat
On Mon, 5 Aug 2024 at 19:36, Gerald Pfeifer wrote:
>
> On Mon, 22 Jul 2024, Jonathan Wakely wrote:
> >> We have been carrying this note on the "original" export feature for ages,
> >> and I believe it's not actually a FAQ, if it ever was.
> >>
>
On Wed, 7 Aug 2024 at 08:09, Filip Kastl wrote:
>
> On Tue 2024-08-06 17:00:24, Gerald Pfeifer wrote:
> > > +
> > > +The following headers are used less widely in libstdc++ and may need to
I like Gerald's suggestion to change this to "within libstdc++" as
that is more precise about that change.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/text_encoding: Fix indentation.
---
libstdc++-v3/include/std/text_encoding | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/std/text_encoding
b/libstdc++-v3/
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test now fails in C++26 mode because the declaration in is
constexpr and the one in the test isn't. Add constexpr to the test.
libstdc++-v3/ChangeLog:
PR libstdc++/115744
* testsuite/18_support/headers/new/synopsis.cc [C++26]:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We've already declared optional at the top of the header, so don't need
to do it again.
libstdc++-v3/ChangeLog:
* include/std/optional: Remove redundant redeclaration.
---
libstdc++-v3/include/std/optional | 3 ---
1 file changed, 3 deleti
On Wed, 21 Aug 2024 at 09:48, Filip Kastl wrote:
>
> Hi,
>
> this is the second version of my patch. See version 1 here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659584.html
>
> Changes made:
> - Removed plural when referring to the single changed header. From the two
> versio
Tested x86_64-linux. Pushed to trunk.
Probably worth backporting too. It could potentially cause new errors
for people using arrays in std::variant, but that's forbidden by the
standard.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/116381
* include/std/variant (variant): Fix co
On Wed, 21 Aug 2024 at 09:55, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> Probably worth backporting too. It could potentially cause new errors
> for people using arrays in std::variant, but that's forbidden by the
> standard.
Notably, both lib
Tested x86_64-linux.
This should improve compile times for C++20 and up.
I need to test this with Clang, but then I plan to push it if all goes
well.
-- >8 --
For C++20 the __detail::__variant::_Uninitialized primary template can
be used for all types, because _Variant_union can have a non-triv
On Wed, 21 Aug 2024 at 10:03, Andrew Pinski wrote:
>
> On Wed, Aug 21, 2024 at 1:56 AM Jonathan Wakely wrote:
> >
> > Tested x86_64-linux. Pushed to trunk.
> >
> > Probably worth backporting too. It could potentially cause new errors
> > for people usin
This is still pending a decision by LEWG, but I've pushed it to trunk anyway.
We can always revert it before GCC 15 is released if the committee
decides against it, but this way we might get user feedback on it.
On Thu, 1 Aug 2024 at 22:41, Jonathan Wakely wrote:
>
> Tested x
On Wed, 21 Aug 2024 at 13:58, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not
> sure if the current specification of 'projected' strictly speaking
> allows for this optimization, but it seems like a natural one that
> should be allowed.
Yeah, I can't s
On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14?
>
> -- >8 --
>
> This implements the changes of this C++23 paper as a DR against C++20.
It's a little unfortunate that we can't bump the __cpp_lib_ranges
macro for C+
On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14?
>
> -- >8 --
>
> This implements the changes of this C++26 paper as a DR against C++20.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/iterator_concepts.h (in
On Wed, 21 Aug 2024 at 18:18, Patrick Palka wrote:
>
> On Wed, 21 Aug 2024, Jonathan Wakely wrote:
>
> > On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > >
Tested x86_64-linux. I plan to push this soon.
-- >8 --
Currently iterators for unordered containers do not directly define
operator== and operator!= overloads. Instead they rely on the base class
defining them, which is done so that iterator and const_iterator
comparisons work using the same ove
ead of rand().
* testsuite/25_algorithms/random_shuffle/88935.cc: New test.
Co-authored-by: Jonathan Wakely
Signed-off-by: Giovanni Bajo
---
libstdc++-v3/include/bits/stl_algo.h | 42 +++
.../25_algorithms/random_shuffle/88935.cc | 24 +++
2 files changed, 57 inser
On Thu, 22 Aug 2024 at 14:31, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
> perhaps 14?
OK for trunk and gcc-14.
We didn't backport the fix to move ranges::iota to , so the
iota.cc test will need adjustment on the branch.
>
> -- >8 --
>
> libstdc++-v
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The standard says this constructor should be private. LWG 4141 proposes
to remove it entirely. We still need it, but it doesn't need to be
public.
For std::bitset the default constructor is already private (and never
even defined) but there's a non
On Wed, 21 Aug 2024 at 10:03, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> This should improve compile times for C++20 and up.
>
> I need to test this with Clang, but then I plan to push it if all goes
> well.
It seems to work OK with Clang, so I've pushed it.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* src/c++11/debug.cc: Replace throw() with noexcept.
---
libstdc++-v3/src/c++11/debug.cc | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libstdc++-v3/src/c++11/d
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We need to be able to attach debug mode iterators to const containers,
so the safe iterator constructor uses const_cast to get a modifiable
pointer to the container. If the container was defined as const, that
const_cast to access its members results
Tested x86_64-linux. Pushed to trunk.
-- >8 --
LWG 436 confirmed that const-qualified types are valid arguments for
Facet template parameters (but volatile-qualified types are not). Use the
fast path in std::use_facet and std::has_facet for const T as well as T.
libstdc++-v3/ChangeLog:
Tested x86_64-linux. OK for trunk?
-- >8 --
This includes uncommenting the atomic_flag non-member functions, which
were added by PR libstdc++/103934.
Also generate a hint for std::ignore, which was recently tweaked to be
more generally useful by P2968R2, which r15-2324 implemented.
gcc/cp/Chang
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This avoids constraint recursion in operator<=> for std::optional.
The resolution was approved in Kona 2022.
libstdc++-v3/ChangeLog:
* include/std/optional (__is_derived_from_optional): New
concept.
(operator<=>): Use __is_d
Pushed to trunk.
-- >8 --
The main fix here is to use @header so that the docs show the correct
header file instead of an internal header like alloc_traits.h.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h: Improve doxygen docs for
allocator_traits specializations.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/tuple: Do not include implementation details in
Doxygen documentation.
---
libstdc++-v3/include/std/tuple | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/s
Pushed to trunk.
-- >8 --
There are lots of bugs that affect libstdc++ output from Doxygen, so
using 1.9.6 or later is recommended. Give a lower minimum, because some
distros still use 1.9.1 and that will work, albeit suboptimally.
libstdc++-v3/ChangeLog:
* doc/xml/manual/documentation_
On Sat, 24 Aug 2024 at 14:14, Jason Merrill wrote:
>
> On 8/23/24 8:41 AM, Jonathan Wakely wrote:
> > Tested x86_64-linux. OK for trunk?
>
> OK.
I've just noticed that this changes the copyright dates from 2022-2024
to just 2024 (see the excerpts of the patch retained be
On Sat, 24 Aug 2024 at 14:55, Jonathan Wakely wrote:
>
> On Sat, 24 Aug 2024 at 14:14, Jason Merrill wrote:
> >
> > On 8/23/24 8:41 AM, Jonathan Wakely wrote:
> > > Tested x86_64-linux. OK for trunk?
> >
> > OK.
>
> I've just noticed that this ch
901 - 1000 of 10280 matches
Mail list logo
