On Tue, 19 Mar 2024 at 09:31, Jonathan Wakely wrote:
>
> On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
> >
> > Both committed now.
> >
> > Just to confirm, those 2 last patches should be backported to gcc-13
> > branch, right ?
>
> Yes plea
Tested x86_64-linux. Pushed to trunk.
I've taken the liberty of assuming that the change to
gcc/doc/install.texi is sufficiently "obviously true" to not require
separate approval.
-- >8 --
This is a generated header but regenerating it requires the manual step
of running 'make -C include
Pushed to trunk.
-- >8 --
There are several more sub-directories below 'src' now, with lots more
conveience libraries. Document them all as of GCC 14.
Also document how to regenerate the generated headers under include/bits
and how to update the tzdata.zi file.
libstdc++-v3/ChangeLog:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These scripts both print "generated by $file, do not edit" header but
one of them prints the wrong filename. Use the built-in __file__
attribute to ensure it's correct.
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Fix header
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This has been reported upstream.
libstdc++-v3/ChangeLog:
* testsuite/util/pstl/test_utils.h: Fix typos in comments.
---
libstdc++-v3/testsuite/util/pstl/test_utils.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's
On Tue, 19 Mar 2024 at 10:55, Iain Sandoe wrote:
>
> Note that Windows-based platforms do something quite similar, but always
> use the same (x.exe) filename. I wonder, in passing, if that makes a
> vulnerability in parallel testing (I chose to avoid the possibility for
> Darwin).
Parallel
On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
>
> Both committed now.
>
> Just to confirm, those 2 last patches should be backported to gcc-13
> branch, right ?
Yes please.
>
> I might have a try to update version.h but if you want to do it before
> don't hesitate.
You'll need to have
On Mon, 18 Mar 2024 at 16:46, Kaz Kylheku wrote:
>
> On 2024-03-18 00:30, Jonathan Wakely wrote:
> >>+@item __EXP_COUNTER__
> >>+This macro's name means "(macro) expansion counter".
> >>+Outside of macro replacement sequences, it expands to the integer
On Sun, 17 Mar 2024 at 16:52, François Dumont wrote:
>
>
> >
> > OK for trunk, thanks!
> >
> > I think this is OK to backport to 13 too.
> >
> > Maybe after this we can define the __cpp_lib_null_itetators macro for
> > debug mode?
> >
> After this fix of local_iterator I think we can indeed.
>
>
On Sun, 17 Mar 2024 at 18:14, François Dumont wrote:
>
> I was a little bit too confident below. After review of all _M_singular
> usages I found another necessary fix.
>
> After this one for sure we will be able to define
> __cpp_lib_null_iterators even in Debug mode.
>
> libstdc++: Fix
On 18/03/24 07:30 +, Jonathan Wakely wrote:
On 21/04/22 04:31 -0700, Kaz Kylheku wrote:
libcpp/ChangeLog
2022-04-21 Kaz Kylheku
This change introduces a pair of related macros
__EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
integer values which
On 21/04/22 04:31 -0700, Kaz Kylheku wrote:
libcpp/ChangeLog
2022-04-21 Kaz Kylheku
This change introduces a pair of related macros
__EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
integer values which enumerate macro expansions.
They can be used for
: New test case.
> > * testsuite/23_containers/vector/debug/114316.cc: New test case.
> >
> > Tested under Linux x86_64, ok to commit ?
>
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macro for
OK for trunk?
-- >8 --
The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
Refer to both forms by name, rather than using "the former" for one and
referring to the other by name.
gcc/ChangeLog:
* doc/invoke.texi (Diagnostic Message Formatting Options):
Replace
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The fast path for "{}" format strings has a bug for negative integers
where the length passed to std::to_chars is too long.
libstdc++-v3/ChangeLog:
PR libstdc++/114325
* include/std/format (_Scanner::_M_scan): Pass correct length
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
I forgot to update the commit log to remove the speculation, because
Stephan Lavavej confirmed that MSVC doesn't mark those functions
nodiscard because it would result in too many false positives. Although
it might find some real bugs, it
Should we do this to silence the deprecation messages from the TBB
headers we include?
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/101228
* include/pstl/parallel_backend_tbb.h
(TBB_SUPPRESS_DEPRECATED_MESSAGES):
Define before including then undef afterwards.
---
On Fri, 16 Feb 2024 at 15:15, Jonathan Wakely wrote:
>
> On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
> >
> > On Fri, Feb 16, 2024 at 01:51:54PM +0000, Jonathan Wakely wrote:
> > > Ah, although __atomic_compare_exchange only takes pointers, the
> > >
Pushed to trunk. I should backport this too.
-- >8 --
The bug with exceptions thrown during a std::call_once call affects all
targets, so fix the docs that say it only affects non-Linux targets.
libstdc++-v3/ChangeLog:
PR libstdc++/66146
* doc/xml/manual/status_cxx2011.xml:
I think we have all C++23 changes in this table now. At some point soon
we should replace the C++20 table of papers with the C++20 table of
contents, as we do for the other standards.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Update C++23
Tested with GDB 14.1 on x86_64-linux. I'll backport this too.
-- >8 --
A recent GDB change causes this test to fail due to missing RTTI for the
custom_cast type. This is presumably because the custom_cat type was
defined as a local class, so has no linkage. Moving it to local scope
seems to fix
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug.xml: Improve docs on debug builds and
using ASan. Mention _GLIBCXX_ASSERTIONS. Reorder sections to put
the most relevant ones first.
* doc/xml/manual/using.xml: Add comma.
*
On Thu, 7 Mar 2024 at 12:07, Jonathan Wakely wrote:
>
> Any objection to this update to make the docs reflect reality?
Pushed to trunk now.
>
> -- >8 --
>
> The macro-based concept checks are unmaintained and do not support C++11
> or later, so reject valid code. If nob
Every year I have to scroll down further and further to the useful part,
and I'm getting too old to spend my time doing that! :)
I suggested this on IRC and iains agreed. What do others think?
-- >8 --
This seems more useful with the recent history first.
---
htdocs/develop.html | 819
On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze wrote:
>
> Previously, calling erase(key) on both std::map and std::set
> would execute that same code that std::multi{map,set} would.
> However, doing that is unnecessary because std::{map,set}
> guarantee that all elements are unique.
>
> It is
On Sat, 9 Mar 2024 at 12:18, Jonathan Wakely wrote:
>
>
>
> +template
>> + __wait_result_type
>> + __wait_for(const __platform_wait_t* __addr, __wait_args __args,
>> +const chrono::duration<_Rep, _Period>& __rtime) noexcep
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 furt
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When parsing a std::chrono::sys_days (or a sys_time with an even longer
period) we should not require a time-of-day to be present in the input,
because we can't represent that in the result type anyway.
Rather than trying to decide which
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Implementing all chrono::from_stream overloads in terms of
chrono::sys_time meant that a leap second time like 23:59:60.001 cannot
be parsed, because that cannot be represented in a sys_time.
The fix to support parsing leap seconds as utc_time is
Tested x86_64-linux. Pushed to trunk.
-- >8 --
With std::from_chars we can parse subsecond durations much faster than
with std::num_get, as shown in the microbenchmarks below. We were using
std::num_get and std::numpunct in order to parse a number with the
locale's decimal point character. But
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When converting a chrono::duration to a result type with an
integer representation we should use chrono::round<_Duration> so that we
don't truncate towards zero. Rounding ensures that e.g. 0.001999s
becomes 2ms not 1ms.
We can also remove some
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The whole point of these typedefs is to guarantee lock-freedom, so if
the target has no such types, we shouldn't defined the typedefs at all.
libstdc++-v3/ChangeLog:
PR libstdc++/114103
* include/bits/version.def
Pushed to trunk.
On Fri, 1 Mar 2024 at 15:09, Jonathan Wakely wrote:
> Does the text of these new diagnostics look good?
>
> There are of course other ways for a type to be not-formattable (e.g.
> the formatter::format member doesn't return the right type or has some
> other ki
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the
library, there's the one defined inline in (to avoid loading
the tzdb for the common case) and another in a testcase. This updates
them to note that there are no new leap
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I don't see why we should rely on __builtin_memset etc. in tests. We can
just include and use the public API.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/deque/allocator/default_init.cc: Use
std::memset instead of
Any objection to this update to make the docs reflect reality?
-- >8 --
The macro-based concept checks are unmaintained and do not support C++11
or later, so reject valid code. If nobody plans to update them we should
consider removing them. Alternatively, we could ignore the macro for
C++11 and
On Tue, 5 Mar 2024 at 18:31, Joseph Myers wrote:
>
> On Tue, 5 Mar 2024, Jakub Jelinek wrote:
>
> > I can't bisect that far, supposedly predefined macros weren't included back
> > in 1996 when this was written but maybe it changed in 1999 or even earlier.
>
> It looks like this changed in 3.0 (so
OK for trunk?
Or am I missing something and the docs are right? (sometimes? always?)
-- >8 --
The manual has always claimed that -dD differs from -dM by not
outputting predefined macros, but that's untrue. It has been untrue
since at least GCC 3.2 and probably even older.
gcc/ChangeLog:
On 01/03/24 15:38 -0500, Jason Merrill wrote:
On 3/1/24 14:24, Marek Polacek wrote:
+@smallexample
+template
+[[gnu::no_dangling(std::is_reference_v)]] int foo (T& t) @{
I think this function should return a reference.
The condition in the attribute can only ever be true if you call this
Is this OK for trunk?
-- >8 --
I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
regenerating these files. They should be touched by gcc_update so they
aren't regenerated unnecessarily.
contrib/ChangeLog:
* gcc_update: Add more generated files in libcc1,
This fixes a regression on all active branches.
Tested aarch64-linux.
-- >8 --
I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
Does the text of these new diagnostics look good?
There are of course other ways for a type to be not-formattable (e.g.
the formatter::format member doesn't return the right type or has some
other kind of incorrect signature, or the formatter::parse member isn't
constexpr) but we can't
Does this look reasonable to push? There are lots of other uses of
AM_ENABLE_MULTILIB(, ..) in the tree, but I'll leave others to "fix"
those if needed.
-- >8 --
This seems to be needed to build with --enable-maintainer-mode but I
don't understand why it doesn't fail in the normal build.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
std::basic_format_arg::handle is supposed to format its value as const
if that is valid, to reduce the number of instantiations of the
formatter's format function. I made a silly typo so that it checks
formattable_with not formattable_with,
which
Tested aarch64-linux, powerpc-linux (power 7 BE), x86_64-linux.
The bug reporter tested it on s390x too.
Pushed to trunk. This should be backported too.
-- >8 --
The change in r11-2981-g2f983fa69005b6 meant that
std::lexicographical_compare_three_way started to use memcmp for
unsigned integers
We need to add [[nodiscard]] to the comparison ops in
too, which I missed in the v1 patch.
Tested aarch64-linux. Pushed to trunk (yesterday).
commit 26d6a714b29eeef77591f136f5162622a549d8fd
Author: Jonathan Wakely
Date: Mon Feb 26 13:09:02 2024
libstdc++: Add more nodiscard uses
Oops, sorry, I CC'd the wrong Victor on this patch (you've both
reported libstdc++ bugs today and I grabbed the email address from the
wrong browser tab).
On Wed, 28 Feb 2024 at 14:53, Jonathan Wakely wrote:
>
> Tested x86_64-linux, pushed to trunk. Backport to gcc-13 to follow.
>
Tested x86_64-linux, pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
The PR points out that the destructors all have incorrect
noexcept-specifiers.
libstdc++-v3/ChangeLog:
PR libstdc++/114152
* include/experimental/scope (scope_exit scope_fail): Make
destructor
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/appendix_contributing.xml: Change URLs to use
https.
* doc/html/manual/*: Regenerate.
---
.../doc/html/manual/appendix_contributing.html | 8
Pushed to trunk, but I've just noticed it should be https not http.
-- >8 --
We don't want a separate ChangeLog submission now.
libstdc++-v3/ChangeLog:
* doc/xml/manual/appendix_contributing.xml: Replace outdated
info on ChangeLog entries.
*
I'd like to be able to link directly to this part of the page from other
docs.
OK for wwwdocs?
---
htdocs/gitwrite.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index c89cdb8f..54f8005a 100644
--- a/htdocs/gitwrite.html
+++
ght thing, and should just add tests to verify that.
commit e1c689dbeb5b6364eb2a2f0af20ced07b8096b82
Author: Jonathan Wakely
Date: Thu Feb 22 13:06:59 2024
libstdc++: Test error handling in std::print
The standard requires an exception if std::print fails to write to a
FILE*. When writing
Ooops, I forgot to add --no-numbered so these were eight unrelated
patches, not PATCH 1/8 .. PATCH 8/8. Sorry for any confusion.
On Tue, 27 Feb 2024 at 14:33, Jonathan Wakely wrote:
>
> On Tue, 27 Feb 2024 at 11:49, Jonathan Wakely wrote:
> >
> > Tested x86_64-linux. I th
On Tue, 27 Feb 2024 at 11:49, Jonathan Wakely wrote:
>
> Tested x86_64-linux. I think we should make this change, because
> otherwise we define the typedefs for platforms with no lock-free
> atomics, like hppa-hpux. Instead of lying, those typedefs should be
> absent on that ta
Tested x86_64-linux. I think we should make this change, because
otherwise we define the typedefs for platforms with no lock-free
atomics, like hppa-hpux. Instead of lying, those typedefs should be
absent on that target.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/114103
*
Tested x86_64-linux. I am unable to test this on Cygwin myself. Testing
and reviews invited.
-- >8 --
Cygwin should use std::fwrite, not WriteConsoleW. And the -lstdc++exp
library is only needed when running the tests on *-*-mingw*.
libstdc++-v3/ChangeLog:
* include/std/ostream
Tested x86_64-linux. Reviews invited.
-- >8 --
The bitwise operators for combining bitmask types such as std::launch
are not consistently annotated with noexcept, constexpr, and nodiscard.
This is the subject of LWG 3977, although the proposed resolution
doesn't work. We can make the changes in
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (vector::at): Add
nodiscard.
* include/bits/stl_vector.h (vector::at): Likewise.
(operator==, operator<=>, operator<, operator!=, operator>)
(operator<=,
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h:
* testsuite/25_algorithms/unique/1.cc: Add dg-warning.
* testsuite/25_algorithms/unique/11480.cc: Likewise.
* testsuite/25_algorithms/unique_copy/26133.cc: Likewise.
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/stacktrace: Add nodiscard attribute to all
functions without side effects.
---
libstdc++-v3/include/std/stacktrace | 36 +
1 file changed, 31 insertions(+), 5
Tested x86_64-linux. Reviews invited.
-- >8 --
The standard requires an exception if std::print fails to write to a
std::ostream.
libstdc++-v3/ChangeLog:
* include/std/ostream (vprint_nonunicode): Throw if stream state
indicates writing failed.
*
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h: Include for
__make_move_if_noexcept_iterator.
---
libstdc++-v3/include/bits/alloc_traits.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
Pushed to trunk as obvious.
-- >8 --
gcc/ChangeLog:
* doc/invoke.texi (Warning Options): Fix typos.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d75b28484bb..b4e4ee9fb81 100644
---
On Tue, 20 Feb 2024 at 18:43, François Dumont wrote:
>
>libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_wrap behavior
>
> In _GLIBCXX_DEBUG mode the std::__niter_base can remove 2 layers, the
> __gnu_debug::_Safe_iterator<> and the __gnu_cxx::__normal_iterator<>.
> When
the rest and didn't notice anything else wrong.
>
> Thanks,
> Peter D.
Thanks. I've fixed it with the attached patch, pushed to wwwdocs.
commit d472f751802f95635997649ea7ec71e4f725aa50
Author: Jonathan Wakely
Date: Mon Feb 19 20:44:12 2024 +
Fix "using using"
ess hot/cold partitioning for the array allocators.
> * libsupc++/Makefile.in: Regenerated.
>
> Signed-off-by: Iain Sandoe
> Co-authored-by: Jonathan Wakely
> ---
> libstdc++-v3/configure | 35 +++---
> libstdc++-v3/configure.ac
On Mon, 19 Feb 2024, 08:12 Jonathan Wakely, wrote:
>
>
> On Mon, 19 Feb 2024, 07:08 Stephan Bergmann, wrote:
>
>> On 2/17/24 15:14, François Dumont wrote:
>> > Thanks for the link, tested and committed.
>>
>> I assume this is the cause for the below fa
On Mon, 19 Feb 2024, 07:08 Stephan Bergmann, wrote:
> On 2/17/24 15:14, François Dumont wrote:
> > Thanks for the link, tested and committed.
>
> I assume this is the cause for the below failure now,
>
Yes, the new >= C++11 overload of __niter_base recursively unwraps multiple
layers of
I had another change to in my local tree which affected
the second dg-error and I "fixed" it unnecessarily. I've tested with a
clean tree this time.
Tested aarch64-linux. Pushed to trunk.
-- >8 --
PR libstdc++/87744
PR libstdc++/113961
libstdc++-v3/ChangeLog:
*
On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
>
> On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> > Ah, although __atomic_compare_exchange only takes pointers, the
> > compiler replaces that with a call to __atomic_compare_exchange_n
> > which t
On Fri, 16 Feb 2024 at 12:38, Jonathan Wakely wrote:
>
> On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
> >
> > Thank you for your careful review!
> >
> > > But we don't need a new one if it's going to be used in exactly one test
> > > and if the new
On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
>
> Thank you for your careful review!
>
> > But we don't need a new one if it's going to be used in exactly one test
> > and if the new option does the same thing for all targets that run the test.
> Got it, thanks. Now add option "-latomic" directly,
Tested x86_64-linux, pushed to trunk.
-- >8 --
PR libstdc++/87744
PR libstdc++/113931
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
---
libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc | 4 ++--
1
Pushed to trunk.
-- >8 --
The configure option is no longer necessary.
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug_mode.xml: Update docs for backtraces.
* doc/html/manual/debug_mode_using.html: Regenerate.
---
libstdc++-v3/doc/html/manual/debug_mode_using.html | 9 -
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Fix spelling of elements.
* doc/html/manual/test.html: Regenerate.
---
libstdc++-v3/doc/html/manual/test.html | 4 ++--
libstdc++-v3/doc/xml/manual/test.xml | 4 ++--
2 files changed, 4
On Thu, 15 Feb 2024 at 18:38, François Dumont wrote:
>
> On 15/02/2024 14:17, Jonathan Wakely wrote:
>
>
>
> On Wed, 14 Feb 2024 at 21:48, François Dumont
> wrote:
>
>>
>> On 14/02/2024 20:44, Jonathan Wakely wrote:
>>
>>
>>
>
On Wed, 14 Feb 2024 at 21:48, François Dumont wrote:
>
> On 14/02/2024 20:44, Jonathan Wakely wrote:
>
>
>
> On Wed, 14 Feb 2024 at 18:39, François Dumont
> wrote:
>
>> libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior
>>
>> std::__niter_bas
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
-- >8 --
As pointed out in the PR we already do this for reset().
libstdc++-v3/ChangeLog:
PR libstdc++/113807
* include/std/bitset (bitset::set()): Use memset instead of a
loop over the individual words.
---
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
-- >8 --
Signed 64-bit division is much slower than unsigned, so cast the n and
k values to unsigned before doing n %= k. We know this is safe because
neither value can be negative.
libstdc++-v3/ChangeLog:
PR libstdc++/113811
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
-- >8 --
The unused bits in the high word are already zero before this operation.
Shifting the used bits to the right cannot affect the unused bits, so we
don't need to sanitize them.
libstdc++-v3/ChangeLog:
PR libstdc++/113806
Tested aarch64-linux. Pushed to trunk.
This should be backported to gcc-13 too.
-- >8 --
Import the new 2024a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).
libstdc++-v3/ChangeLog:
* src/c++20/tzdata.zi: Import new file
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
This should be backported too, as it's a regression fix.
-- >8 --
The call to __valarray_copy constructs an _Array object to refer to
this->_M_data but that means that accesses to this->_M_data are through
a restrict-qualified pointer.
Tested aarch64-linux and x86_64-linux (-m64 and -m32).
Pushed to trunk.
-- >8 --
For 32-bit targets without __int128 we need to implement the LCG
transition function by hand using 64-bit types.
We can also slightly simplify the __mod function by using if-constexpr
unconditionally, disabling
On Wed, 14 Feb 2024 at 18:39, François Dumont wrote:
> libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior
>
> std::__niter_base is used in _GLIBCXX_DEBUG mode to remove _Safe_iterator<>
> wrapper on random access iterators. But doing so it should also preserve
> original
> behavior to
On Mon, 12 Feb 2024 at 22:17, Patrick Palka wrote:
> On Mon, 12 Feb 2024, Paul Keir wrote:
>
> > A call to `basic_string::clear()` in the std::string move assignment
> operator leads to a constexpr error from an access of inactive union member
> `_M_local_buf` in the added test (`test_move()`).
traits (is_same): Use
> > _GLIBCXX_USE_BUILTIN_TRAIT instead of
> > _GLIBCXX_HAVE_BUILTIN_IS_SAME.
> > (is_same_v): Likewise.
>
> LGTM
>
Me too, OK for trunk, thanks.
+Reviewed-by: Jonathan Wakely
>
> >
> > Signed-off-by: Ken Matsui
> > ---
> > libst
Tested aarch64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h: Fix typo in comment.
---
libstdc++-v3/include/bits/shared_ptr_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested aarch64-linux. Pushed to trunk.
-- >8 --
There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.
libstdc++-v3/ChangeLog:
PR libstdc++/100147
* include/bits/gslice.h (operator=): Add comment about lack
On Thu, 8 Feb 2024 at 16:02, Jonathan Wakely wrote:
> Tested x86_64-linux. Pusued to trunk. I'll backport it too.
>
Only to gcc-13 though, because __has_builtin(__bases) is false for gcc-12.
Tested x86_64-linux. Pusued to trunk. I'll backport it too.
-- >8 --
These non-standard extensions use GCC-specific built-ins. Use
__has_builtin to avoid errors when Clang compiles this header.
See https://github.com/llvm/llvm-project/issues/24289
libstdc++-v3/ChangeLog:
*
On Wed, 7 Feb 2024, 19:20 Patrick Palka, wrote:
> On Wed, 7 Feb 2024, Jonathan Wakely wrote:
>
> >
> >
> > On Wed, 7 Feb 2024 at 17:29, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
> > OK
On Wed, 7 Feb 2024 at 17:29, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
OK.
Do we have a reduced testcase to track the modules bug that will still
exist in the FE?
>
> -- >8 --
>
> The forward declarations of std::get in added in
>
well, and OK for both if all goes well.
> Without this backport, I see this failure on arm-none-eabi:
>
> FAIL: 23_containers/vector/bool/110807.cc (test for excess errors)
>
> Kind regards,
> Torbjörn
>
>
> On 2023-11-09 02:22, Jonathan Wakely wrote:
> >
> >
> Without this backport, I see these failures on arm-none-eabi:
>
> FAIL: 29_atomics/atomic/compare_exchange_padding.cc (test for excess
> errors)
> FAIL: 29_atomics/atomic_ref/compare_exchange_padding.cc (test for excess
> errors)
>
Yes, OK
>
> Kind regards,
> T
On Mon, 5 Feb 2024, 19:07 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-13?
>
OK, thanks
> ---
>
> When running the DejaGNU testsuite on a toolchain built for native
> Windows, the path /dev/null can't be used to open a stream to void.
> On native Windows, the resource is instead
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
Teted x86_64-linux. Pushed to trunk.
-- >8 --
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.
-- >8 --
This fails due to "u" being used in a system header.
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
101 - 200 of 9534 matches
Mail list logo
