We still have __is_arithmetic in after this,
but that needs a lot more work to remove its uses from and
.
Tested x86_64-linux.
-- >8 --
This removes the std::__is_pointer and std::__is_scalar traits, as they
conflicts with a Clang built-in.
Although Clang has a hack to make the class template
Tested x86_64-linux.
-- >8 --
This removes the std::__is_void trait, as it conflicts with a Clang
built-in. There is only one use of the trait, which can easily be
replaced by simpler code.
Although Clang has a hack to make the class template work despite using
a reserved name, removing std::__i
Tested x86_64-linux.
-- >8 --
This replaces all uses of the std::__is_pointer type trait with uses of
the new __is_pointer built-in. Since the class template was only used to
enable some performance optimizations for algorithms, we can use the
built-in when __has_builtin(__is_pointer) is true (wh
Tested x86_64-linux.
-- >8 --
Dispatching to partial specializations doesn't really seem to offer much
benefit here. The __is_trivial(T) condition is a compile-time constant
so the untaken branches are dead code and don't cost us anything.
libstdc++-v3/ChangeLog:
* include/bits/valarray
Tested x86_64-linux.
-- >8 --
This member function was previously deprecated, but that was reverted by
P2875R4, approved earlier this year in Tokyo. Since it's not going to be
deprecated in C++26, and so presumably not removed, there is no point in
giving deprecated warnings for C++23 mode.
libs
Tested x86_64-linux.
-- >8 --
These tests compile very slowly in debug mode.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_modifying_operations/rotate_copy.cc:
Increase timeout for debug mode.
*
testsuite/25_algorithms/pstl/alg_mo
Tested x86_64-linux.
-- >8 --
LWG 3305 was approved earlier this year in Tokyo. We need to give an
error if using std::any_cast, but std::any_cast is valid
(but always returns null).
libstdc++-v3/ChangeLog:
* include/std/any (any_cast(any*), any_cast(const any*)): Add
static ass
Tested x86_64-linux.
-- >8 --
These were deprecated in C++17 and std::wstring_convert is planned for
removal in C++26.
libstdc++-v3/ChangeLog:
* include/bits/locale_conv.h (wstring_convert): Add deprecated
attribute for C++17 and later.
(wbuffer_convert): Likewise.
Tested x86_64-linux.
-- >8 --
This addresses one known failure due to a bug in the upstream tests, and
a number of timeouts due to the algorithms running much more slowly with
debug mode checks enabled.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/al
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/backward/backward_warning.h: Adjust comments to
suggest as another alternative to .
* include/backward/strstream (strstreambuf, istrstream)
(ostrstream, strstream): Add deprecated attribute.
---
...
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a warning from one of the test allocators:
warning: base class 'class std::allocator<__gnu_test::copy_tracker>' should be
explicitly initialized in the copy constructor [-Wextra]
libstdc++-v3/ChangeLog:
* testsuite/util/testsuit
Pushed to trunk now. Backport to gcc-14 needed too.
On Thu, 20 Jun 2024 at 16:27, Jonathan Wakely wrote:
>
> This unfortunately means we can never increase __cpp_lib_chrono again
> for the old string ABI, but I don't see any alternative (except
> supporting chrono::tzdb for the
Pushed to trunk now.
On Wed, 19 Jun 2024 at 17:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux. Not pushed yet. backports will be needed too.
>
> -- >8 --
>
> Due to PR c++/85723 the std::is_trivial trait is true for types with a
> deleted default constructor, so the u
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/backward/backward_warning.h: Adjust comments to
> suggest as another alternative to .
>
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:38, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> These were deprecated in C++17 and std::wstring_convert is planned for
> removal in C++26.
>
> libstdc++-v3/ChangeLog:
>
> * include
Pusahed to trunk now.
On Thu, 20 Jun 2024 at 16:41, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This member function was previously deprecated, but that was reverted by
> P2875R4, approved earlier this year in Tokyo. Since it's not going to be
Tested x86_64-linux. Pushed to trunk. Probably worth backporting.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (uninitialized_default_construct)
(uninitialized_default_construct_n, uninitialized_value_construct)
(uninitialized_value_construct_n): Qu
Pushed to trunk now. I might backport this later too.
On Thu, 20 Jun 2024 at 16:39, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> LWG 3305 was approved earlier this year in Tokyo. We need to give an
> error if using std::any_cast, but std::any_cas
Oops, this patch series actually depends on
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
was posted separately, but needs to be applied before 4/4 in this
series.
On Thu, 20 Jun 2024 at 16:35, Jonathan Wakely wrote:
>
> We still have __is_arithmetic in after this,
On Fri, 21 Jun 2024 at 16:07, Matthias Kretz wrote:
>
>
> * Running a test compiled with AVX512 instructions requires
> avx512f_runtime not just avx512f.
>
> * The 'reduce2' test violated an invariant of fixed_size_simd_mask and
> thus failed on all targets without 16-Byte vector builtins enabled
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:28, Jonathan Wakely wrote:
>
> I think the new conditions are correct. They're certainly an improvment
> on just checking __is_scalar without considering what we're assigning it
> to.
>
> Tested x86_64-linux.
>
> --
This series (and the patch it depends on) have been pushed to trunk now.
On Fri, 21 Jun 2024 at 10:31, Jonathan Wakely wrote:
>
> Oops, this patch series actually depends on
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html which
> was posted separately, but needs t
On Mon, 24 Jun 2024 at 21:33, Alexandre Oliva wrote:
>
>
> libatomic hasn't been ported to vxworks. Most of the stdatomic.h and
> underlying requirements are provided by builtins and libgcc,
> and the vxworks libc already provides remaining __atomic symbols, so
> porting libatomic doesn't seem t
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
>
> On 6/18/24 10:31, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
>
> Makes sense to me, though probably the [meta.unary.prop] table should be
> adjusted in the same way. Jonathan, what do you think
Gerald noticed these stale viewcvs links. I'll push this to trunk later
this week, and backport too.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/faq.xml: Replace viewcvs links with cgit links.
* doc/xml/manual/allocator.xml: Likewise.
* doc/xml/manual/mt_allocator.xml: Lik
Please read https://gcc.gnu.org/contribute.html#patches and ensure
you've included everything, for example ...
On 22/06/24 17:11 -0400, Shengdun Wang wrote:
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose en
On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote:
>
> On 6/25/24 07:15, Jonathan Wakely wrote:
> > On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
> >>
> >> On 6/18/24 10:31, Marek Polacek wrote:
> >>> Bootstrapped/regtested on x86_64-pc-linux-gnu,
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Change reference from
mainline GCC to the release branch.
* doc/html/manual/status.html: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html | 3 +--
libstdc++-v3/doc/xml/manual/status_cxx2023.xml | 3
Pushed to gcc-12.
-- >8 --
When I tried to make the release branch versions of these docs refer to
the release branch instead of "mainline GCC", for some reason I left the
text "not any particular release" there. That's just confusing, because
the docs are for a particular release, the latest on
Pushed to gcc-13.
-- >8 --
When I tried to make the release branch versions of these docs refer to
the release branch instead of "mainline GCC", for some reason I left the
text "not any particular release" there. That's just confusing, because
the docs are for a particular release, the latest on
On Tue, 25 Jun 2024 at 23:34, Jonathan Wakely wrote:
>
> Pushed to gcc-13.
And the equivalent for gcc-14 too.
>
> -- >8 --
>
> When I tried to make the release branch versions of these docs refer to
> the release branch instead of "mainline GCC", for some
This script automates some updates that should be made when branching
from trunk. Putting them in a script makes it much easier and means I
won't forget what should be done.
Any suggestions for doing this differently?
Anything I've forgotten that should be added here?
We could add an entry to th
Pushed to trunk.
On Thu, 20 Jun 2024 at 16:34, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> Dispatching to partial specializations doesn't really seem to offer much
> benefit here. The __is_trivial(T) condition is a compile-time constant
>
This is the final version, which is the same as v1 except for the typo
in a comment fixed, as noted in my May 2nd email.
Tested x86_64-linux, pushed to trunk.
-- >8 --
I found some issues in the std::chrono::tzdb parser by testing the
tzdata "vanguard" format, which uses new features that aren't
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:36, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This addresses one known failure due to a bug in the upstream tests, and
> a number of timeouts due to the algorithms running much more slowly with
>
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:36, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> These tests compile very slowly in debug mode.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90276
> *
> testsuite/25_a
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We currently have 808590.cc which only runs for C++98 mode, and
808590-cxx11.cc which only runs for C++11 and later, but have almost
identical content (except for a defaulted special member in the C++11
one, to suppress a -Wdeprecated-copy warning).
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 it
exists when we branch ;-)
On Wed, 26 Jun 2024 at 00:13, Jonathan Wakely wrote:
>
> This script automates some updates that should be made when branc
On Mon, 22 Jul 2024 at 07:51, Gerald Pfeifer 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.
>
> Jonathan moved this down when adding a note on ADL last fall.
>
> I now propose to drop it.
>
> Thoughts?
On Mon, 22 Jul 2024 at 14:54, Filip Kastl wrote:
>
> Hi Tamar,
>
> I wanted to try reviewing a patch and this seemed simple enough so I gave it a
> shot. Hopefully this saves some time of the maintainer that eventually
> approves this :).
>
> I don't see any bug in the code. I also tried running
Tested x86_64-linux.
-- >8 --
Use the dg-additional-files directive to declare files that need to be
copied into the test's working directory. This is currently redundant
(as all .tst and .txt files are copied for all tests) but is a step
towards not copying all files.
libstdc++-v3/ChangeLog:
Tested x86_64-linux.
-- >8 --
This adds a new dg-final action to compare two files after a test has
run, so that we can verify that fstream operations produce the expected
results. With this change, all uses of @diff@ that seem potentially
useful have been converted to actually compare the files
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/hash/chi2_q_document_words.cc: Use
dg-additional-files for input text.
* testsuite/performance/ext/pb_ds/all_text_find.cc: Likewise.
* testsuite/performance/ext/pb_ds/multimap_text_find.hpp:
Tested x86_64-linux.
-- >8 --
These have the wrong PR number in the filenames.
libstdc++-v3/ChangeLog:
PR libstdc++/12048
* testsuite/ext/stdio_sync_filebuf/wchar_t/12948-1.cc: Move to...
* testsuite/ext/stdio_sync_filebuf/wchar_t/12048-1.cc: ...here.
* testsuite
Tested x86_64-linux.
-- >8 --
We can replace the @require@ markup with { dg-additional-files ... }
directives, so that the required files are explicitly named and are
explicitly copied into place for tests that require it. This will allow
a later change to remove the "Copy all required data files
Tested x86_64-linux.
-- >8 --
Use the dg-additional-files directive to declare files that need to be
copied into the test's working directory. This is currently redundant
(as all .tst and .txt files are copied for all tests) but is a step
towards not copying all files.
libstdc++-v3/ChangeLog:
Tested x86_64-linux.
-- >8 --
We have a number of 27_io/* tests with comments like this:
// @require@ %-*.tst
// @diff@ %-*.tst %-*.txt
It seems that these declare required data files used by the test and a
post-test action to compare the test output with the expected result.
We do have tests t
Tested x86_64-linux.
-- >8 --
This removes the TODO in libstdc++_init, so that we don't copy all *.tst
and *.txt files from testsuite/data into every test's working directory.
Instead, only the necessary files declared with dg-additional-files are
copied.
libstdc++-v3/ChangeLog:
* tests
I'm pushing this workaround from Detlef.
I incorrectly assumed that is enough to ensure isatty is
present, but that isn't true for avr-libc.
It might be cleaner to add a proper autoconf check for isatty and dup,
but we don't have any reports of it failing for other targets. This
simple workaroun
Tested x86_64-linux, built on avr.
Pushed to trunk.
-- >8 --
This avoids some warnings when the preprocessor conditions are not met.
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__open_terminal): Use [[maybe_unused]] on
parameter.
---
libstdc++-v3/src/c++23/print.cc | 4 ++--
On Mon, 22 Jul 2024 at 20:53, Michael Levine wrote:
>
> The bits/stl_algobase.h header was added to bits/ranges_algobase.h separately
> through two related commits:
>
> https://github.com/gcc-mirror/gcc/commit/674d213ab91871652e96dc2de06e6f50682eebe0
>
> https://github.com/gcc-mirror/gcc/commit/0b
I've pushed this series to trunk now.
On Mon, 22 Jul 2024 at 17:34, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> We have a number of 27_io/* tests with comments like this:
>
> // @require@ %-*.tst
> // @diff@ %-*.tst %-*.txt
>
> It see
Tested x86_64-linux.
Pushed to trunk. Backports to follow after the 14.2 release.
-- >8 --
This questionable combination of flags causes a number of errors. The
ones in the rvalue stream overloads need to be fixed in the gcc-14
branch so I'm committing it separately to simplify backporting.
lib
Tested x86_64-linux.
Pushed to trunk. Backports to follow after the 14.2 release.
-- >8 --
This questionable combination of flags causes a number of errors. This
one in std::vector needs to be fixed in the gcc-13 branch so I'm
committing it separately to simplify backporting.
libstdc++-v3/Chang
Tested x86_64-linux.
Any reason not to do this? I don't think the assertions are useful to
catch implementation bugs where we access the contained value without
checking it - we should use tests for that.
-- >8 --
Currently we implement the precondition for accessing the contained
value of a std
Tested x86_64-linux.
-- >8 --
Now that _base::_M_get() doesn't check the precondition, we can use
_M_get() instead of operator*() for the internal uses where we've
already checked the precondition holds.
Add a using-declaration so that we don't need to lookup _M_get in the
dependent base class,
Tested x86_64-linux.
-- >8 --
In C++20 mode we can simplify some of the std::optional base class
hierarchy using concepts. We can overload the destructor and copy
constructor and move constructor with a trivial defaulted version and a
constrained non-trivial version. This allows us to remove some
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/optional (optional): Constrain constructors to
prevent problematic bool conversions, as per LWG 3836.
* testsuite/20_util/optional/cons/lwg3836.cc: New test.
---
libstdc++-v3/include/std/optional
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/expected (expected): Constrain constructors to
prevent problematic bool conversions, as per LWG 3836.
* testsuite/20_util/expected/lwg3836.cc: New test.
---
libstdc++-v3/include/std/expected
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/expected (bad_expected_access): Add noexcept
to special member functions, as per LWG 4031.
* testsuite/20_util/expected/bad.cc: Check for nothrow copy and
move members.
---
libstdc++-v3/include/s
On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen
wrote:
>
> On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
> >
> > Tested x86_64-linux.
> >
> > Any reason not to do this? I don't think the assertions are useful to
> > catch implementation bugs wh
On Wed, 24 Jul 2024 at 20:58, Jonathan Wakely wrote:
>
> On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen
> wrote:
> >
> > On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
> > >
> > > Tested x86_64-linux.
> > >
> > > Any reason n
On Thu, 25 Jul 2024, 02:58 Andrew Pinski, wrote:
> The problem here is that v3_additional_files will have a space
> at the begining of the string as dg-additional-files will append
> `" " $files` to it. Then when split is called on that string,
> there will be an empty file and copying a dir wil
On Thu, 25 Jul 2024 at 07:32, Jonathan Wakely wrote:
>
>
>
> On Thu, 25 Jul 2024, 02:58 Andrew Pinski, wrote:
>>
>> The problem here is that v3_additional_files will have a space
>> at the begining of the string as dg-additional-files will append
>> `" &q
On Thu, 25 Jul 2024 at 01:04, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 (after
> 14.2 is released)?
Yes to both, thanks.
>
> -- >8 --
>
> The type of an implicit object parameter is always the current class.
> For an explicit object parameter however
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For C++20 mode we can improve compile times by using conditional
explicit to reduce the number of constructor overloads. We can also use
requires-clauses instead of SFINAE to implement constraints on the
constructors and assignment operators.
libstd
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/optional: Reorder parameters in comparison
operators as per LWG 2945.
---
libstdc++-v3/include/std/optional | 36 +++
1 file changed, 18 insertions(+), 18 deletions(-
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/expected (expected::value): Add assertions for LWG
3843 requirements.
(expected::value): Add assertions for LWG 3940
requirements.
---
libstdc++-v3/include/std/expected | 8 +
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This was recently approved for C++26, but we can apply the changes for
all modes back to C++11. There's no reason not to make the assignment
usable in constant expressions for C++11 mode, and noexcept for all
modes.
Move the definitions to so they'
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There's no valid use case for default constructing this type, so the
committee approved removing the default constructor.
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_args): Remove default
constructor, as per LWG 4106.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the numbers in PR libstdc++/88545 show, the manual loop unrolling in
std::__find_if doesn't actually help these days, and it prevents the
compiler from auto-vectorizing.
Remove the dispatching on iterator_category and just use the simple loop
for
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Cast ptrdiff_t to size_t to avoid a -Wsign-compare warning. We can check
in __to_chars_i that the ptrdiff_t won't be negative, so that we know
the cast is safe.
libstdc++-v3/ChangeLog:
* include/std/charconv (__to_chars_16, __to_chars_10)
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The resolution was implemented in r14-8752-g6f75149488b74a but I didn't
add the usual _GLIBCXX_RESOLVE_LIB_DEFECTS comment.
libstdc++-v3/ChangeLog:
* include/bits/std_function.h: Add comment about LWG 3617 being
supported.
---
libs
Jeff approved an earlier version of this as trivially OK (since it
doesn't affect anybody not using b4). The v2 patch that I've pushed adds
the send-series-to config, as suggested by the b4 maintainer here:
https://lore.kernel.org/tools/20240523143752.385810-1-jwak...@redhat.com/T/#mb21ebe04b433442
Bootstrapped on x86_64-linux and for msp430-elf cross with and without
binutils for the target to verify the error is printed as expected.
The $invoked variable will be one of as, collect-ld, nm, or dsymutil,
i.e. the tool that the script is invoking and wants to exec.
OK for trunk?
-- >8 --
Wh
On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
wrote:
>
> Hi,
>
>
> I'm attaching two files:
>
> 1.: to_chars10.h:
>
> This is intended to be included in libstdc++ / gcc to achieve performance
> improvements. It is an implementation of
>
> to_chars10(char* first, char* last, /* integer-type
On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely wrote:
>
> On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
> wrote:
> >
> > Hi,
> >
> >
> > I'm attaching two files:
> >
> > 1.: to_chars10.h:
> >
> > This is intended to be incl
On 15/03/24 13:02 +, Jonathan Wakely wrote:
OK for trunk?
Ping
-- >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:
On Mon, 29 Jul 2024 at 17:02, Thomas Schwinge wrote:
>
> Hi Jonathan!
>
> On 2024-07-22T17:28:38+0100, Jonathan Wakely wrote:
> > This adds a new dg-final action to compare two files after a test has
> > run, [...]
>
> Nice!
>
> > --- a/libstdc++-v3/testsu
My first attempt to fix this was an overly complex kluge, but there was
a nice simple solution staring me in the face. I'm pretty happy with
this now.
Tested x86_64-linux.
-- >8 --
When formatting a chrono::zoned_time with an empty chrono-specs, we were
only formatting its _M_time member, but th
Tested x86_64-linux.
-- >8 --
This implements the proposed resolution of LWG 4124, so that
low-resolution chrono::zoned_time objects can be formatted. The
formatter for zoned_time needs to account for get_local_time
returning local_time> not local_time.
libstdc++-v3/ChangeLog:
* include
reliable.
* testsuite/27_io/filesystem/operations/hard_link_count.cc: New
test.
Signed-off-by: "Lennox" Shou Hao Ho
Reviewed-by: Jonathan Wakely
diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 07bc2a0fa88
On Tue, 30 Jul 2024, 06:21 Ehrnsperger, Markus,
wrote:
> On 2024-07-29 12:16, Jonathan Wakely wrote:
>
> > On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely
> wrote:
> >> On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
> >> wrote:
> >>>
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
On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
>
> Hi,
>
> And this is the corresponding change libstdc++.
Thanks for the patch. Do you have a copyright assignment for GCC in
place, or are you covered by a corporate assignment for KDAB?
If not, please complete that process, or contribute
On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
wrote:
>
> Hello!
>
> The attached patch implements adds support for P2591R5 in libstdc++
> (concatenation of strings and string_views, approved in Tokyo for C++26).
Thanks for this patch as well. This was on my TODO list so I'll be
happy to not hav
On Tue, 30 Jul 2024 at 14:08, Jonathan Wakely wrote:
>
> On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
> wrote:
> >
> > Hello!
> >
> > The attached patch implements adds support for P2591R5 in libstdc++
> > (concatenation of strings and string_vie
This LWG issue is about to become Tentatively Ready.
Tested x86_64-linux.
-- >8 --
This uses remove_cv_t for the default template argument used for
deducing a type for a braced-init-list used with std::optional and
std::expected.
libstdc++-v3/ChangeLog:
* include/std/expected (expected
I've pushed this for https://github.com/msys2/MSYS2-packages/issues/1937
but I'm taking a slightly different approach to Björn's original patch.
Instead of adding __detail::equivalent_win32 I'm adding fs::equiv_files
to do the check for both POSIX and Windows. The logic in do_copy_file
should be
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc: Fix file name in comment.
---
libstdc++-v3/src/c++17/fs_ops.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 7ffdce677
On Tue, 30 Jul 2024 at 22:54, Giuseppe D'Angelo
wrote:
>
> On 30/07/2024 15:27, Jonathan Wakely wrote:
> > On Tue, 30 Jul 2024 at 14:08, Jonathan Wakely wrote:
> >>
> >> On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
> >> wrote:
> >>>
On Tue, 30 Jul 2024 at 23:49, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> On 30/07/2024 15:04, Jonathan Wakely wrote:
> > On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
> >>
> >> Hi,
> >>
> >> And this is the corresponding chang
I doubt we want the @euro suffix anywhere except Glibc-based targets. We
certainly don't want to append "@euro" on Solaris, where this change
flips some tests from UNSUPPORTED to PASS, e.g.
21_strings/basic_string/numeric_conversions/char/to_string_float.cc
It will probably also cause some to flip
On Wed, 31 Jul 2024 at 13:27, Jonathan Wakely wrote:
>
> I doubt we want the @euro suffix anywhere except Glibc-based targets. We
> certainly don't want to append "@euro" on Solaris, where this change
> flips some tests from UNSUPPORTED to PASS, e.g.
> 21_strings/ba
On Wed, 31 Jul 2024 at 13:42, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > On Wed, 31 Jul 2024 at 13:27, Jonathan Wakely wrote:
> >>
> >> I doubt we want the @euro suffix anywhere except Glibc-based targets. We
> >> certainly don't want to append &
As discussed a couple of weeks ago, I'm going to push this.
Tested x86_64-linux (where this #else isn't even used, but I checked it
does at least compile when the #if isn't true).
-- >8 --
The linux man page for strerror says that some systems return NULL for
an unknown error number. That violat
On Wed, 31 Jul 2024 at 15:42, Björn Schäpers wrote:
>
> Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
> > 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/M
On Wed, 31 Jul 2024 at 16:45, Sam James wrote:
>
> We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
> one.
>
> libstdc++-v3/ChangeLog:
> * testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do run'.
> ---
> OK? No regressions in the logs but it's a bit wei
It took a while, but I was finally happy with this v4 patch, so I pushed
it to trunk. Then I noticed silly mistake in the new test, which I'll
fix shortly.
Compared to v3 sent two weeks ago, the main change here is the addition
of a mutex to the __encoding facet, so that two formatters using the
s
On Wed, 31 Jul 2024 at 19:17, Dimitar Dimitrov wrote:
>
> On Wed, Jul 31, 2024 at 05:09:52PM +0100, Jonathan Wakely wrote:
> > It took a while, but I was finally happy with this v4 patch, so I pushed
> > it to trunk. Then I noticed silly mistake in the new test, which I&
1101 - 1200 of 10092 matches
Mail list logo
