Tested x86_64-linux. Pushed to trunk.
I'm going to push this to gcc-13 and gcc-14 too (approved by Jakub on
IRC).
-- >8 --
We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.
libstdc++-v3/ChangeLog:
PR libstdc++/114863
*
Pushed to gcc-14.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml:
Pushed to gcc-13.
-- >8 --
This should have been done before the 13.1.0 release.
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml:
Pushed to trunk. I'll also be following this with the non-whitespace
equivalents for the gcc-14 and gcc-13 branches.
-- >8 --
This simplifies the changes needed after branching for a new release, so
that new line breaks don't need to be introduced every time we branch.
libstdc++-v3/ChangeLog:
On Thu, 18 Apr 2024 at 21:34, Jonathan Wakely wrote:
>
> On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
> >
> > This completes the fixes to put all experimental symbols into
> > libstdc++exp.a.
> >
> > On trunk the libstdc++_libbacktrace.a was removed
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
The Doxygen-generated man pages for some new types need to be renamed to
use '::' instead of '_' in the filenames.
libstdc++-v3/ChangeLog:
* scripts/run_doxygen: Rename man pages for nested types.
---
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
Doxygen switched from \fC to \fR in its man page output:
https://github.com/doxygen/doxygen/pull/10497
This breaks our script that expects \fC so change the regaulr expression
to work with either style.
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
---
libstdc++-v3/include/std/chrono | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/doxygen/stdheader.cc (init_map): Add missing headers.
* doc/doxygen/user.cfg.in (EXCLUDE): Exclude generated files for
std::format and std::text_encoding.
---
Tested x86_64-linux. Pushed to trunk.
-- >8 --
It's not obvious why needs so add a
comment to it.
libstdc++-v3/ChangeLog:
* include/std/variant: Add comment to #include.
---
libstdc++-v3/include/std/variant | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Pushed to gcc-13
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
> all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
> but that wasn't true. Only the symbols from the latte
On Tue, 23 Apr 2024 at 17:05, Jakub Jelinek wrote:
>
> On Mon, Apr 22, 2024 at 11:14:35PM -0400, Jason Merrill wrote:
> > > > The following testcase regressed with Marek's r14-5979 change,
> > > > when pr113208_0.C is compiled where the ctor is marked constexpr,
> > > > we no longer perform this
strict-flex-arrays): Spelling fix: inproper -> improper.
> gcc/cp/
> * parser.cc (cp_parser_using_declaration): Spelling fix: favour
> -> favor.
> gcc/m2/
> * lang.opt (fuse-list=): Spelling fix: finalializations ->
> finalizations.
LGTM
+Reviewed-by: Jonathan Wakely
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK, thanks
>
> - 8< -
>
>
> Avoid
> -Wnarrowing in C
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK
>
> - 8< -
>
> Signed-off-by: Matthias Kretz
>
>
On Mon, 22 Apr 2024 at 16:37, Jakub Jelinek wrote:
>
> Hi!
>
> We see
> FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess
OK for wwwdocs?
---
htdocs/gcc-14/changes.html | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Instead of constraining these overloads in terms of synth-three-way we
can just check that the value_type is less-than-comparable, which is
what synth-three-way's constraints check.
The reason that I implemented these with constraints has now been
On Fri, 19 Apr 2024 at 10:08, Jonathan Wakely wrote:
>
> On Fri, 19 Apr 2024 at 07:14, Richard Biener
> wrote:
> >
> > On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> > >
> > > This would fix the but, how do people feel about it this close to
On Thu, 18 Apr 2024 at 22:59, Patrick Palka wrote:
>
> On Wed, 17 Apr 2024, Michael Levine (BLOOMBERG/ 919 3RD A) wrote:
>
> > This patch fixes GCC Bug 108760:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> > Before this patch, using std::ranges::iota required including
> > when it
On Fri, 19 Apr 2024 at 07:14, Richard Biener wrote:
>
> On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> >
> > This would fix the but, how do people feel about it this close to the
> > gcc-14 release?
>
> Guess we'll have to fix it anyway, so why not now .
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> This completes the fixes to put all experimental symbols into
> libstdc++exp.a.
>
> On trunk the libstdc++_libbacktrace.a was removed completely and its
> contents aded to libstdc++exp.a instead. We don't want to do th
is that we don't increase the
installed footprint of gcc-13 by duplicating all the backtrace symbols
in two static archives. We could even consider making libstdc++fs.a a
symlink to libstdc++exp.a as well, on trunk and gcc-13, to stop
duplicating those symbols.
-- >8 --
Jonathan Wakely (2):
l
This completes the fixes to put all experimental symbols into
libstdc++exp.a.
On trunk the libstdc++_libbacktrace.a was removed completely and its
contents aded to libstdc++exp.a instead. We don't want to do that on the
gcc-13 branch because it will break makefiles using it. We can add the
In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
but that wasn't true. Only the symbols from the latter were added to
libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
libtool won't
On Thu, 18 Apr 2024 at 17:33, Jonathan Wakely wrote:
>
> This would fix the but,
*fix the bug
> how do people feel about it this close to the
> gcc-14 release?
>
> Tested x86_64-linux.
This would fix the but, how do people feel about it this close to the
gcc-14 release?
Tested x86_64-linux.
-- >8 --
Since 2022 the TZif format defined in the zic(8) man page has said that
links can refer to other links, rather than only referring to a zone.
This isn't supported by the C++20
Tested x86_64-linux and x86_64-freebsd. Pushed to trunk.
-- >8 --
This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature.
On Wed, 17 Apr 2024 at 09:17, Matthias Kretz wrote:
>
> This never showed up as an issue because it's an internal header and
> implicitly guarded by bits/simd.h.
>
> OK for trunk? Any reason to backport?
OK for trunk, I think it's worth backporting too.
>
> - 8<
On Wed, 17 Apr 2024 at 08:58, Matthias Kretz wrote:
>
> Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
>
> OK for trunk and backports?
OK, thanks.
>
> - 8< --
>
> This resolves failing tests in check-simd.
>
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* config/locale/dragonfly/numeric_members.cc: Fix typos in
comments.
* config/locale/gnu/numeric_members.cc: Likewise.
---
libstdc++-v3/config/locale/dragonfly/numeric_members.cc | 4 ++--
On Tue, 16 Apr 2024 at 04:37, Alexandre Oliva wrote:
>
>
> A number of libstdc++ tests that implicitly instantiate
> __to_chars_i and also link floating_to_chars.o in
> fail on vxworks kernel mode. The platform doesn't support undefweak
> symbols (the kernel module loader fails to load modules
On Tue, 16 Apr 2024 at 04:49, Alexandre Oliva wrote:
>
>
> On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
> padding bits in the tests are not what we might expect from full-word
> struct copies.
Aha, I was wondering why this was failing on ARM!
> I tried adding a function
On Tue, 16 Apr 2024, 04:19 Alexandre Oliva, wrote:
>
> Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
> adjusted about a year ago to skip long double on some targets, because
> the fastfloat library was limited to 64-bit doubles.
>
> The same problem comes up in similar
On Tue, 16 Apr 2024, 04:17 Alexandre Oliva, wrote:
>
> VxWorks fails to load kernel-mode modules with weak undefined symbols.
> In RTP mode modules, that undergo final linking, weak undefined
> symbols are not a problem.
>
> This patch adds kernel-mode VxWorks multilibs to the set of targets
>
Pushed to trunk now.
On Mon, 8 Apr 2024 at 17:53, Jonathan Wakely wrote:
>
> Patch v2.
>
> I realised that it's not only negative delim values that cause the
> problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
> will cause traits_t
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++20 and later it seems OK for trunk now.
>
> -- >8 --
>
> I'm only treating this as a DR for C++20 for now, because it's less work
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:53, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++26 it seems OK for trunk now.
>
> -- >8 --
>
> This C++26 change was just approved in Tokyo, in P2944R3. It adds
> operator== an
On Thu, 11 Apr 2024 at 15:51, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When we are already touching this topic, here is a patch like r13-5126
> > which documents the upcoming release symbol versions in the
On Mon, 15 Apr 2024 at 14:01, Andreas Schwab wrote:
>
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
OK for trunk and gcc-13, thanks.
> ---
> .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On Fri, 12 Apr 2024, 21:51 H.J. Lu, wrote:
> * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:
> Updated.
>
OK thanks
---
> .../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
>
I'm considering this late patch for gcc-14 to workaround an issue
discovered by a recent Clang change.
I'm not yet sure if Clang is right to require these symbols. It's not
really clear, because always_inline isn't part of the standard so it's
not clear how it should interact with explicit
On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
>
> Hi!
>
> When we are already touching this topic, here is a patch like r13-5126
> which documents the upcoming release symbol versions in the documentation.
>
> Ok for trunk?
OK, thanks.
>
> 2024-04-11 Jakub Jelinek
>
> *
On Thu, 11 Apr 2024 at 15:46, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> >>
On Thu, 11 Apr 2024 at 15:36, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj
> > 2024-04-11 15:55:49.982325397 +0200
> > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
On Thu, 11 Apr 2024 at 15:18, Jakub Jelinek wrote:
>
> Hi!
>
> While the previous patch was regeneration from 13.2 release (with hand
> edits for arches I don't have libraries for but which are still well
> maintained), thius one is regeneration from the trunk (this time for
> hand edits
On Thu, 11 Apr 2024 at 15:13, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote:
> >
> > On Apr 11 2024, Jakub Jelinek wrote:
> >
> > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj
> > &g
On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj
> > 2023-05-04 09:42:43.277271065 +0200
> > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> >
On Thu, 11 Apr 2024 at 15:07, Jakub Jelinek wrote:
>
> On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> > I think we also want the same change for i386.
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> > *
I think we also want the same change for i386.
-- >8 --
libstdc++-v3/ChangeLog:
* config/abi/post/i386-linux-gnu/baseline_symbols.txt:
Regenerate.
---
.../config/abi/post/i386-linux-gnu/baseline_symbols.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Thu, 11 Apr 2024 at 14:52, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch regenerates the ABI files for 13 branch (I've only changed
> the Linux files which were updated in r13-7289, all but m68k, riscv64 and
> powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
>
I plan to push this shortly, to fix the P1 ABI regression that Jakub
reported earlier today.
This will trigger 'make check-abi' failures for CI testers, because the
baseline_sybols.txt wasn't regenerated for gcc 13.2.0 and so there are
two symbols present in GLIBCXX_3.4.32 which are not in the
On Thu, 25 Jan 2024 at 15:54, Christophe Lyon
wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
>
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
The std/time/year_month_day/io.cc test assumes that %x in the fr_FR
locale is %d/%m/%Y but on FreeBSD it is %d.%m.%Y instead. Make the test
PASS for either format.
Similarly, 27_io/manipulators/extended/get_time/char/2.cc
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
Although POSIX requires ELOOP, FreeBSD documents that openat with
O_NOFOLLOW returns EMLINK if the last component of a filename is a
symbolic link. Check for EMLINK as well as ELOOP, so that the TOCTTOU
mitigation in remove_all
I think this is considerably nicer than the macro version, but it can
definitely wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__compare): New
function template.
(operator==, operator!=, operator<, operator>, operator<=)
Tested x86_64-linux.
Since this only affects C++20 and later (except for adding [[nodiscard]]
to relational ops) it seems OK for trunk now.
-- >8 --
Implement the changes from P2944R3 which add constraints to the
comparison operators of std::pair, std::tuple, and std::variant.
The paper also
Tested x86_64-linux.
This is just a minor clean-up and could wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE):
Simplify.
---
libstdc++-v3/include/std/variant | 20 +---
1 file changed, 9
Tested x86_64-linux.
Since this only affects C++26 it seems OK for trunk now.
-- >8 --
This C++26 change was just approved in Tokyo, in P2944R3. It adds
operator== and operator<=> overloads to std::reference_wrapper.
The operator<=> overloads in the paper cause compilation errors for any
type
Tested x86_64-linux.
Since this only affects C++20 and later it seems OK for trunk now.
-- >8 --
I'm only treating this as a DR for C++20 for now, because it's less work
and only requires changes to operator== and operator<=>. To do this for
older standards would require changes to the six
Tested x86_64-linux. Richi confirmed this fixes rx-elf bootstrap.
Pushed to trunk.
-- >8 --
If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.
This fixes a build error for targets where __cpp_lib_to_chars is not
Patch v2.
I realised that it's not only negative delim values that cause the
problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
will cause traits_type::find to match 'a' but then the eq_int_type
comparison will fail because (int)'a' != (int)('a' + 256).
This version of the
I recently disabled _Utf8_view for -fno-char8_t, but we can just make it
use char instead of char8_t. The existing uses of it in the library are
unaffected.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Instead of just omitting the definition of __unicode::_Utf8_view when
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Adjust expected errors or skip tests as UNSUPPORTED if -fno-char8_t is
used in the test flags.
libstdc++-v3/ChangeLog:
* testsuite/20_util/integer_comparisons/equal_neg.cc: Use
no-opts selector for errors that
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.
On Thu, 4 Apr 2024 at 17:55, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote:
> Ulrich's suggestion is to allow the buggy user code to Just Work (for
> all cases except (char)-1 on a platform where char is signed). That is
> maybe the least surpr
On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote:
> >
> >
> >
> > > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote:
> > >
> > > I would appreciate more eyes on this to confirm
On Thu, 4 Apr 2024 at 17:33, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote:
> >
> > On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote:
> > > I would appreciate more eyes on this to confirm my conclusions about
> > > negati
On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote:
>
> On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote:
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
>
> The way someth
On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote:
>
>
>
> > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote:
> >
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
> >
I would appreciate more eyes on this to confirm my conclusions about
negative int_type values, and the proposed fix, make sense.
Tested x86_64-linux.
-- >8 --
A negative value for the delim value passed to std::istream::ignore can
never match any character in the stream, because the comparison
Tested x86_64-linux. Pushed to trunk. Backports likely to follow.
-- >8 --
This is a workaround for a possible compiler bug that causes constraint
recursion in the operator<=>(const optional&, const U&) overload.
libstdc++-v3/ChangeLog:
PR libstdc++/104606
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view): Guard with check for
char8_t being enabled.
(__literal_encoding_is_unicode): Guard use of char8_t with check
for it being
On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote:
>
> Just out of curiosity: would this also work?
>
> template
> struct _Absent {};
>
> template
> using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, _Disc>>;
>
> That would avoid having to type 0, 1, ... manually.
This is
On Tue, 2 Apr 2024 at 08:47, Jakub Jelinek wrote:
>
> Hi!
>
> Like in r12-7519-g027e30414492d50feb2854aff38227b14300dc4b, I've done
> git grep -v 'long long\|optab optab\|template template\|double double' | grep
> ' \([a-zA-Z]\+\) \1 '
>
> This is just part of the changes, mostly for non-gcc
On Mon, 1 Apr 2024 at 23:16, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This is a layout change for some specializations of slide_view, but
better to do that now than change it between gcc 14 and 15.
OK for trunk.
>
> -- >8 --
>
> Currently
On Wed, 27 Mar 2024 at 12:48, Matthias Kretz wrote:
>
> And one more to fix follow-up / remaining failures. Tested on x86_64-linux-
> gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> 8< --
>
> This resolves further failures (-Wreturn-type warnings) and test
>
On Wed, 27 Mar 2024 at 12:13, Richard Sandiford
wrote:
>
> Matthias Kretz writes:
> > On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
> >> I'm still worried about:
> >>
> >> #if _GLIBCXX_SIMD_HAVE_SVE
> >> constexpr inline int __sve_vectorized_size_bytes =
On Fri, 8 Mar 2024 at 09:58, Matthias Kretz wrote:
>
> Hi,
>
> I applied and did extended testing on x86_64 (no regressions) and aarch64
> using qemu testing SVE 256, 512, and 1024. Looks good!
>
> While going through the applied patch I noticed a few style issues that I
> simply turned into a
On Wed, 27 Mar 2024 at 08:51, Matthias Kretz wrote:
>
> This is broken on GCC 13 and 14 (https://compiler-explorer.com/z/GPKGPGs6T)
>
> Tested on x86_64-linux-gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> --- 8< -
>
> This resolves failures in
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> Thoughts? There are only a few uses for this presently, but I can see it
> being useful often in future. The library exposes which features it
> supports in a standardized way, so we can use those in tests to
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can be r
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator: Fix _V badname.
OK for trunk, thanks.
> ---
> libstdc++-v3/include/std/generator | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> Per the standard, the return type of a generators ranges iterator op*
> should be the reference type rather than the yielded type.
>
> The yielded type was used here by mistake.
>
> libstdc++-v3/ChangeLog:
>
> *
Tested aarch64-linux. Puhed to trunk.
-- >8 --
This was a copy & paste error.
libstdc++-v3/ChangeLog:
* testsuite/std/text_encoding/requirements.cc: #undef the
correct macro.
---
libstdc++-v3/testsuite/std/text_encoding/requirements.cc | 2 +-
1 file changed, 1 insertion(+), 1
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was just approved in Tokyo as a DR for C++23. It doesn't affect us
yet, because we don't implement the __cpp_lib_format_ranges features. We
can add the disabled specializations and add a testcase now though.
libstdc++-v3/ChangeLog:
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
We already have __is_in_place_type_v for in_place_type_t so adding an
equivalent for in_place_index_t allows us avoid a class template
instantiation for the __not_in_place_tag constraint on the most
commonly-used std::variant::variant(T&&)
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The difference between __type_identity_t and std::type_identity_t is
observable, as demonstrated in the PR. Nobody in LWG seems to think this
an example we should really care about, but it seems easy and harmless
to change this.
And this replaces an existing custom dg-require- directive with a use of
the new one that checks for a standard feature test macro. I didn't see
any other existing dg-require-xxx directives that can be replaced like
this.
-- >8 --
Remove the dejagnu code for checking whether std::stacktrace is
Thoughts? There are only a few uses for this presently, but I can see it
being useful often in future. The library exposes which features it
supports in a standardized way, so we can use those in tests to skip
tests for features that aren't available on all targets.
The obvious downside is that
Tested aarch64-linux. Pushed to trunk.
This should be backported to all branches, as the failure to destroy the
allocators in the re-inserted nodes results in potential resource leaks.
-- >8 --
The allocator objects in container node handles were not being destroyed
after the node was
Pushed to trunk. Backport to gcc-13 needed too, as the changes to use
concepts for std::pair constructors are on that branch.
On Tue, 19 Mar 2024 at 15:59, Jonathan Wakely wrote:
>
> This fixes the problem in the PR, which is revealed by the new
> concept-based constraints on
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Put the C++23 generator and tuple_like ones before the C++26 ones.
libstdc++-v3/ChangeLog:
* include/bits/version.def (generator, tuple_like): Move earlier
in the file.
* include/bits/version.h: Regenerate.
---
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The preprocessor checks for __cplusplus in should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler macro not
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Replace std::result_of with std::invoke_result, as specified in the
standard since C++17, to avoid deprecated warnings for std::result_of.
We don't have __invoke_result_t in C++11 mode, so add it as an alias
template for __invoke_result<>::type
ators): Likewise.
>
> François
>
>
> On 20/03/2024 10:02, Jonathan Wakely wrote:
> > On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
> >> Thanks to you doc:
> >>
> >> libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
>
On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
>
> Thanks to you doc:
>
> libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
>
> _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
> can define
> __glibcxx_null_iterators and
Tested x86_64-linux. Pushed to trunk.
Not a regression, but worth backporting.
-- >8 --
The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't
This fixes the problem in the PR, which is revealed by the new
concept-based constraints on std::pair constructors in C++20 mode. That
makes this a C++20 regression, as the PR's example compiles with C++17.
We need something similar for std::basic_string too, which I'll do
later.
Any comments?
Does anybody see any issues with making this change?
The __cpp_constexpr_dynamic_alloc macro is defined with -std=c++2a
since Clang 10.0.0 so this won't result in std::construct_at
disappearing by anybody using libstdc++ with Clang.
Tested x86_64-linux and aarch64-linux. Basic smoke tests
1 - 100 of 9534 matches
Mail list logo
