Re: [PATCH] libstdc++: Add [[nodiscard]] to std::byteswap

On Tue, 30 Nov 2021 at 08:58, Jakub Jelinek via Libstdc++ wrote: > > Hi! > > This patch adds [[nodiscard]] to std::byteswap, because the function > template doesn't do anything useful if the result isn't used. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Yes, thanks.

[committed] libstdc++: Use gender-agnostic pronoun in docs

I've pushed this change for the libstdc++ docs (should be "their"), but didn't notice the typo in the changelog, so I'll fix that tomorrow after the file is regenerated. libstdc++-v3/ChangeLog: * doc/xml/manual/debug_mode.xml: Replace "his or her" with "they". * doc/html/manual/

[committed] libstdc++: Make Asan detection work for Clang [PR103453]

Tested x86_64-linux, pushed to trunk. Clang doesn't define __SANITIZE_ADDRESS__ so use its __has_feature check to detect Asan instead. libstdc++-v3/ChangeLog: PR libstdc++/103453 * config/allocator/malloc_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Define for Cla

[committed] libstdc++: Skip tag dispatching for _S_relocate in C++17

Tested x86_64-linux, pushed to trunk. In C++17 mode all callers of _S_relocate have already done: if constexpr (_S_use_relocate()) so we don't need to repeat that check and use tag dispatching to avoid ill-formed instantiations. libstdc++-v3/ChangeLog: * include/bits/stl_vector.h (v

[committed] libstdc++: Ensure C++20 std::stringstream definitions use correct ABI

Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to trunk. The definitions of the new C++20 members of std::stringstream etc are missing when --with-default-libstdcxx-abi=gcc4-compatible is used, because all the explicit instantiations in src/c++20/sstream-inst.cc are skipped

[committed] libstdc++: Fix fully-dynamic-string build

Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to trunk. My last change to the fully-dynamic-string actually broke it. This fixes the move constructor so it builds, and simplifies it slightly so that more code is common between the fully-dynamic enabled/disabled cases. lib

[committed] libstdc++: Fix tests that fail with fully-dynamic-string

Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to trunk. Fix some tests that assume that a moved-from string is empty, or that default constructing a string doesn't allocate. libstdc++-v3/ChangeLog: * testsuite/21_strings/basic_string/cons/char/moveable.cc: Allow

[committed] libstdc++: Avoid unwanted allocations in filesystem::path

Tested x86_64-linux, pushed to trunk. When using COW strings, accessing _M_pathname[0] and similar non-const accessors can cause the string to "leak", meaning it reallocates itself if it shares ownership with another string object. This causes test failures for --enable-fully-dynamic-string buil

[committed] libstdc++: Optimize ref-count updates in COW std::string

Tested x86_64-linux, pushed to trunk. Most ref-count updates in the COW string are done via the functions in , which will use non-atomic ops when the program is known to be single-threaded. The _M_is_leaked() and _M_is_shared() functions use __atomic_load_n directly, because doesn't provide a lo

[committed] libstdc++: Define std::__is_constant_evaluated() for internal use

Tested x86_64-linux, pushed to trunk. This adds std::__is_constant_evaluated() as a C++11 wrapper for __builtin_is_constant_evaluated, but just returning false if the built-in isn't supported by the compiler. This allows us to use it throughout the library without checking __has_builtin every tim

[committed] libstdc++: Clear RB tree after moving elements [PR103501]

Tested x86_64-linux, pushed to trunk. If the allocator-extended move constructor move-constructs each element into the new container, the contents of the old container are left in moved-from states. We cannot know if those states preserve the container's ordering and uniqueness guarantees, so jus

Re: [committed] libstdc++: Optimize ref-count updates in COW std::string

On Wed, 1 Dec 2021 at 18:16, Florian Weimer wrote: > > * Jonathan Wakely via Libstdc: > > > diff --git a/libstdc++-v3/include/bits/cow_string.h > > b/libstdc++-v3/include/bits/cow_string.h > > index ced395b80b8..4fae1d02981 100644 > > --- a/libstdc++-v3/include/bits/cow_string.h > > +++ b/libstdc+

[committed] libstdc++: Restore unconditional atomic load in COW std::string

On Wed, 1 Dec 2021 at 18:24, Jonathan Wakely wrote: > > On Wed, 1 Dec 2021 at 18:16, Florian Weimer wrote: > > > > * Jonathan Wakely via Libstdc: > > > > > diff --git a/libstdc++-v3/include/bits/cow_string.h > > > b/libstdc++-v3/include/bits/cow_string.h > > > index ced395b80b8..4fae1d02981 100644

Re: [PATCH] libstdc++: Remove broken std::allocator base classes [PR103340]

On Wed, 24 Nov 2021 at 13:25, Jonathan Wakely via Libstdc++ wrote: > > I plan to commit this Real Soon. Please yell if you need these > alternative std::allocator back-ends to stay (and explain how you're > using them when they've been broken for years, and start sending test > results to the gcc

[committed] libstdc++: Allow exception classes to move fully-dynamic strings

Tested powerpc64le-linux using --enable-fully-dynamic-string and x86_64-linux using the default config. Pushed to trunk. The move constructor for the fully-dynamic std::basic_string was not noexcept until recently, so the std::logic_error and std::runtime_error move constructors were defined to m

[PATCH] libstdc++: Do not leak empty COW strings

Apart from "don't bother changing the COW string", does anybody see a reason we shouldn't do this? This passes all tests for normal COW strings and fully-dynamic COW strings. When non-const references, pointers or iterators are obtained to the contents of a COW std::basic_string, the implementati

[PATCH] libstdc++: Fix non-reserved name in std::allocator base class [PR64135]

I'd like to push this to trunk to fix PR64135. It think this fixes the use of a non-reserved name, while preserving the ABI as far as class layout goes. It will break any programs which rely on std::allocator having a __gnu_cxx::new_allocator base class, e.g. so that is_convertible<__gnu_cxx::new_

[wwwdocs] Document --enable-libstdcxx-allocator changes

Pushed to wwwdocs. --- htdocs/gcc-12/changes.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index 000501fb..c2b87a53 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -41,6 +41,11 @@ a work-in-progre

Re: std::basic_string<_Tp> constructor point of instantiation woes?

On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++ wrote: > > When using recent libstc++ trunk with Clang in C++20 mode, > std::u16string literals as in > > > #include > > int main() { > > using namespace std::literals; > > u""s; > > } > > started to cause linker failures due to und

[committed] libstdc++: Simplify emplace member functions in _Rb_tree

Tested powerpc64le-linux, pushed to trunk. This introduces a new RAII type to simplify the emplace members which currently use try-catch blocks to deallocate a node if an exception is thrown by the comparisons done during insertion. The new type is created on the stack and manages the allocation

[committed] libstdc++: Initialize member in std::match_results [PR103549]

Tested powerpc64le-linux, pushed to trunk. This fixes a -Wuninitialized warning for std::cmatch m1, m2; m1=m2; Also name the template parameters in the forward declaration, to get rid of the noise in diagnostics. libstdc++-v3/ChangeLog: PR libstdc++/103549 * include/bits/regex

[PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

Tested x86_64-linux. As noted below, I don't think using symbol versioning to preserve the old behaviour is necessary here. Does anybody want to convince me otherwise? std::condition_variable::wait(unique_lock&) is incorrectly marked noexcept, which means that the __forced_unwind exception used b

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, < libstd...@gcc.gnu.org> wrote: > * Jonathan Wakely via Libstdc: > > > If necessary we could keep the terminate-on-cancellation behaviour as > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > > and export the new b

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote: > > * Jonathan Wakely: > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > > > wrote: > > > > * Jonathan Wakely via Libstdc: > > > > > If necessary we could keep the terminate-on-cancellation behaviour as > > > _ZNSt18condition_v

Re: [PATCH] libstdc++: Skip atomic instructions in _Sp_counted_base::_M_release when both counts are 1

I've pushed this change to trunk now (it was posted and reviewed in stage 1, I just didn't get around to pushing it until now). The final version of the patch is attached to this mail. Thanks for the nice optimization, Maged! On Wed, 4 Aug 2021 at 20:49, Maged Michael via Libstdc++ wrote: > >

Re: [PATCH] c++: Support &typeid(x) == &typeid(y) and typeid(x) == typeid(y) in constant evaluation [PR103600]

On Wed, 8 Dec 2021 at 13:53, Jason Merrill wrote: > During constant evaluation, the operator== could compare the type_info > address instead of the __name address, reducing this to the previous > problem. That makes sense to me. We might still want the libstdc++ changes in case other compilers cho

Re: [PATCH][_GLIBCXX_DEBUG] Enhance std::erase_if for vector/deque

On Sun, 21 Nov 2021 at 11:26, François Dumont via Libstdc++ wrote: > > I tried to use the same approach I used for node based containers but > got ambiguity on erase calls. I think this simple version will do the work. > > libstdc++: [_GLIBCXX_DEBUG] Enhance std::erase_if for vector/deque > >

Re: [PATCH] enable -Winvalid-memory-order for C++ [PR99612]

On Wed, 8 Dec 2021 at 16:49, Martin Sebor wrote: > I don't anticipate this change to lead to the same fallout > because it's unlikely for GCC to synthesize invalid memory > orders out of thin air; Agreed. I don't think we'll have the same kind of issues. 99% of uses of memory orders just use the c

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Wed, 8 Dec 2021 at 00:36, Jonathan Wakely wrote: > > On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote: > > > > * Jonathan Wakely: > > > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > > > > > wrote: > > > > > > * Jonathan Wakely via Libstdc: > > > > > > > If necessary we cou

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Wed, 8 Dec 2021 at 17:36, Ville Voutilainen wrote: > > On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++ > wrote: > > After resolving a PEBKAC issue, here's an incremental diff that > > preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol, > > but adds a new @@GLIBCXX_3.

Re: [PATCH] libstdc++: Skip atomic instructions in _Sp_counted_base::_M_release when both counts are 1

On Wed, 8 Dec 2021 at 19:17, Rainer Orth wrote: > > Hi Jonathan, > > > I've pushed this change to trunk now (it was posted and reviewed in > > stage 1, I just didn't get around to pushing it until now). > > > > The final version of the patch is attached to this mail. > > unfortunately, it breaks So

Re: [PATCH] libstdc++: Skip atomic instructions in _Sp_counted_base::_M_release when both counts are 1

On Wed, 8 Dec 2021 at 19:21, Jonathan Wakely wrote: > > On Wed, 8 Dec 2021 at 19:17, Rainer Orth wrote: > > > > Hi Jonathan, > > > > > I've pushed this change to trunk now (it was posted and reviewed in > > > stage 1, I just didn't get around to pushing it until now). > > > > > > The final version

[committed] libstdc++: Fix undefined shift when _Atomic_word is 64-bit

On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely wrote: > > On Wed, 8 Dec 2021 at 19:21, Jonathan Wakely wrote: > > > > On Wed, 8 Dec 2021 at 19:17, Rainer Orth wrote: > > > > > > Hi Jonathan, > > > > > > > I've pushed this change to trunk now (it was posted and reviewed in > > > > stage 1, I just didn

[committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

These warnings are triggered by perfectly valid code using std::string. They're particularly bad when --enable-fully-dynamic-string is used, because even std::string().begin() will give a warning. Use pragmas to stop the troublesome warnings for copies done by std::char_traits. libstdc++-v3/Chang

Re: [PATCH] libstdc++: Fix non-reserved name in std::allocator base class [PR64135]

On Thu, 2 Dec 2021 at 17:22, Jonathan Wakely via Libstdc++ wrote: > > I'd like to push this to trunk to fix PR64135. The attached patch is what I've pushed to trunk, which adds some doc updates. > It think this fixes the use of a non-reserved name, while preserving the > ABI as far as class layo

Re: [PATCH] libstdc++: Do not leak empty COW strings

On Thu, 2 Dec 2021 at 17:21, Jonathan Wakely via Libstdc++ wrote: > > Apart from "don't bother changing the COW string", does anybody see a > reason we shouldn't do this? This passes all tests for normal COW > strings and fully-dynamic COW strings. Pushed to trunk. > > When non-const references,

[committed] libstdc++: Avoid unnecessary allocations in std::map insertions [PR92300]

Tested powerpc64le-linux, pushed to trunk. Inserting a pair into a map will allocate a new node and construct a pair in the node, then check if the Key is already present in the map. That is because pair is not the same type as the map's value_type. But it only differs in the const-qualification

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Wed, 8 Dec 2021 at 17:26, Jonathan Wakely wrote: > > On Wed, 8 Dec 2021 at 00:36, Jonathan Wakely wrote: > > > > On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote: > > > > > > * Jonathan Wakely: > > > > > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > > > > > > > wrote: > > >

[committed] libstdc++: Implement std::ios_base::noreplace for C++23 [PR59769]

Tested powerpc64le-linux, pushed to trunk. This implements my P2467R0 proposal to support opening an fstream in exclusive mode. The new constant is also supported pre-C++23 as std::ios_base::__noreplace. This proposal hasn't been approved for C++23 yet, but I am confident it will be, as this is

[committed] libstdc++: Fix std::exception_ptr regressions [PR103630]

Tested powerpc64le-linux, pushed to trunk. This restores support for std::make_exception_ptr and for using std::exception_ptr in C++98. Because the new non-throwing implementation needs to use std::decay to handle references the original throwing implementation is used for C++98. We also need t

[committed] libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]

Tested powerpc64le-linux, pushed to trunk. This allows std::make_exception_ptr to be used in a translation unit compiled with -fno-exceptions. This works because the new implementation added for PR 68297 doesn't need to throw or catch anything. The catch is there to handle exceptions from the con

[committed] libstdc++: Remove bogus dg-error for effective-target c++20

Tested powerpc64le-linux, pushed to trunk. This test no longer has additional errors for C++20 mode, so remove the dg-error that is now failing, and the unnecessary dg-prune-output. libstdc++-v3/ChangeLog: * testsuite/20_util/scoped_allocator/69293_neg.cc: Remove dg-error for c+

[committed] libstdc++: Fix ambiguous comparisons for iterators in C++20

Tested powerpc64le-linux, pushed to trunk. Since r11-1571 (c++: Refinements to "more constrained") was changed in the front end, the following comment from stl_iterator.h stopped being true: // These extra overloads are not needed in C++20, because the ones above // are constrained with a req

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

On Fri, 10 Dec 2021 at 00:39, Martin Sebor via Libstdc++ wrote: > > On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote: > > These warnings are triggered by perfectly valid code using std::string. > > They're particularly bad when --enable-fully-dynamic-string is use

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++ wrote: > > On 12/9/21 5:38 PM, Martin Sebor wrote: > > On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote: > >> These warnings are triggered by perfectly valid code using std::string. > >> They're p

[committed] libstdc++: Fix definition of _GLIBCXX_NO_SLEEP config macro

Tested powerpc64le-linux --enable-threads={posix,single}, pushed to trunk. If no OS function to sleep (e.g. nanosleep, usleep, Win32 Sleep etc.) is available then configure defines the macro NO_SLEEP. But this will not get prefixed with "_GLIBCXX_" because include/Makefile.am only does that for m

[committed] libstdc++: Guard mutex and condvar with gthreads macro [PR103638]

Tested powerpc64le-linux --enable-threads={posix,single}, pushed to trunk. The testsuite is now clean for --enable-threads=single (apart from the expected abi-check failures, because the baselines are for the posix thread model). A mutex and condition variable is used for timed waits on atomics

Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

On Fri, 10 Dec 2021 at 15:16, Rasmus Villemoes via Libstdc++ wrote: > > On 10/12/2021 16.06, Olivier Hainque wrote: > > Hello, > > > > The attached patch for libstdc++ / VxWorks helps building > > the library for old versions of the OS, as witnessed with > > VxWorks 6.9 in particular. > > > > It e

Re: [PATCH] libstdc++: Some time_get fixes [PR78714]

On Thu, 9 Dec 2021 at 14:20, Jakub Jelinek wrote: > > Hi! > > The following patch is an attempt to fix various time_get related issues. > Sorry, it is long... > > One of them is PR78714. It seems _M_extract_via_format has been written > with how strftime behaves in mind rather than how strptime be

Re: [PATCH] libstdc++: Add std::time_get %r support [PR71367]

On Fri, 10 Dec 2021 at 12:49, Jakub Jelinek via Libstdc++ wrote: > > Hi! > > This incremental patch adds std::time_get %r support (%p was added already > in the previous patch). The _M_am_fm_format method previously in the header > unfortunately had wrong arguments and so was useless, so the larg

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

On Fri, 10 Dec 2021 at 16:35, Martin Sebor wrote: > > On 12/10/21 3:12 AM, Jonathan Wakely wrote: > > On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++ > > wrote: > >> > >> On 12/9/21 5:38 PM, Martin Sebor wrote: > >>> On 12/9/2

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

On Fri, 10 Dec 2021 at 17:17, Jakub Jelinek wrote: > > On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote: > > On 12/10/21 9:41 AM, Jakub Jelinek wrote: > > > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches > > > wrote: > > > > The above was just a

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

On Fri, 10 Dec 2021 at 17:07, Olivier Hainque via Libstdc++ wrote: > > Hello, > > The attached patch helps fix a build failure of libstdc++ > on some variants of VxWorks where the system headers expose > an "isblank" macro. > > I understand this kind of thing normally is handled through > fixinclu

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

Ping On 09/11/21 17:51 +, Jonathan Wakely wrote: Now that GCC is compiled as C++11 there is no need to keep the C++03 implementation of gnu::unique_ptr. This removes the unique-ptr.h header and replaces it with in system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY. Uses o

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

On 10/12/21 21:20 +, Jonathan Wakely wrote: Ping Oh sorry, Jakub already replied to this (after I mentioned it on IRC) and approved it. Un-ping! On 09/11/21 17:51 +, Jonathan Wakely wrote: Now that GCC is compiled as C++11 there is no need to keep the C++03 implementation of gnu:

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

On Sat, 11 Dec 2021, 10:56 Olivier Hainque via Libstdc++, < libstd...@gcc.gnu.org> wrote: > (Thanks for your feedback Jonathan) > > > On 10 Dec 2021, at 19:24, Jonathan Wakely wrote: > > > > I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks > > has isblank, the configure check

Re: std::basic_string<_Tp> constructor point of instantiation woes?

On Fri, 3 Dec 2021 at 22:38, Jonathan Wakely wrote: > > On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++ > wrote: > > > > When using recent libstc++ trunk with Clang in C++20 mode, > > std::u16string literals as in > > > > > #include > > > int main() { > > > using namespace std::lit

Re: [PATCH RFC] c++: add color to function decl printing

On Sun, 12 Dec 2021 at 05:39, Jason Merrill wrote: > > In reading C++ diagnostics, it's often hard to find the name of the function > in the middle of the template header, return type, parameters, and template > arguments. So let's colorize it, and maybe the template argument bindings > while we'

[committed] libstdc++: Fix std::regex_replace for strings with embedded null [PR103664]

Tested powerpc64le-linux, pushed to trunk. The overload of std::regex_replace that takes a std::basic_string as the fmt argument (for the replacement string) is implemented in terms of the one taking a const C*, which uses std::char_traits to find the length. That means it stops at a null charact

[committed] libstdc++: Make ranges::size and ranges::empty check for unbounded arrays

Tested powerpc64le-linux, pushed to trunk. Passing IncompleteType(&)[] to ranges::begin produces an error outside the immediate context, which is fine for ranges::begin, but it means that we fail to enforce the SFINAE-able constraints for ranges::size and ranges::size. They should not be callable

Re: [PATCH] Complete __gnu_test::basic_string<>::compare support

On Wed, 10 Aug 2022 at 19:31, François Dumont via Libstdc++ wrote: > > Here is another patch to complete __gnu_debug::basic_string<> Standard > conformity. This one is adding the missing compare overloads. > > I also would like to propose to change how __gnu_debug::basic_string<> > is tested. I co

Re: [PATCH] libstdc++: Fixing Error: invalid type argument of unary '*' (have 'int')

On 04/08/22 12:54 -0400, Seija Kijin wrote: Had an error compiling tiny-cuda-nn using gcc 12.1. With this minor patch, I recompiled and the build succeeded. This looks like a bug in the cuda compiler then. The libstdc++ code is correct. N.B. libstdc++ patches need to be CC'd to the libstdc++ l

Re: [PATCH] libstdc++: async: tolerate slightly shorter sleep

On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ wrote: > > On Jun 22, 2022, Alexandre Oliva wrote: > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > aarch64-rtems6. Ok to install? > > The early wakeups are fixed for rtems6.1, so the same question raised at > http

Re: [PATCH] libstdc++: async: tolerate slightly shorter sleep

On Wed, 12 Oct 2022 at 12:41, Jonathan Wakely wrote: > > On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ > wrote: > > > > On Jun 22, 2022, Alexandre Oliva wrote: > > > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > > aarch64-rtems6. Ok to install? > > > > The ea

[PATCH] libgcc: Quote variable in Makefile.in

This isn't very important as the error is harmless, but it's easy to fix and so is one less thing that might confuse people when looking at build logs. OK for trunk? -- >8 -- If the xgcc executable has not been built (or has been removed by 'make clean') then the command to print the multilib di

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > As I promised in > , > I'd like to update our GCC 13 porting_to.html with the following note. > > Does this look OK to commit? Thanks, > > diff --git a/htdocs/gcc-13/porting_

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, 12 Oct 2022 at 23:24, Marek Polacek wrote: > > On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > > > As I promised in > > > , > > > I'd like to

[committed] libstdc++: Use markdown in Doxygen comment

Pushed to trunk. -- >8 -- This makes the comment easier to read in the source, without altering the Doxygen output. libstdc++-v3/ChangeLog: * include/std/iostream: Use markdown in Doxygen comment. --- libstdc++-v3/include/std/iostream | 6 +++--- 1 file changed, 3 insertions(+), 3 dele

[committed] libstdc++: Simplify print_raw function for debug assertions

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- Replace two uses of print_raw where it's clearer to just use fprintf directly. Then the only remaining use of print_raw is as the print_func argument of pretty_print. When called by pretty_print the count is either a positive integer or -1, so w

[committed] libstdc++: Disable all emergency EH pool code if obj-count == 0

Tested x86_64-linux. Pushed to trunk. -- >8 -- For a zero-sized static pool we can completely elide all code for the EH pool. We no longer need to adjust the static buffer size to ensure at least one free_entry can be created in it, because we no longer use a static buffer at all if obj_count ==

Re: libstdc++: Address '-Wunused-function' for 'print_raw' (was: [committed] libstdc++: Simplify print_raw function for debug assertions)

On Sat, 15 Oct 2022 at 11:52, Thomas Schwinge wrote: > > Hi! > > On 2022-10-14T15:36:02+0100, Jonathan Wakely via Gcc-patches > wrote: > > Tested powerpc64le-linux. Pushed to trunk. > > > > -- >8 -- > > > > Replace two uses of print_raw where it&

[committed] libstdc++: Fix uses_allocator_construction args for cv pair (LWG 3677)

This issue is Tentatively Ready, and the resolution seems obviously correct so we can do it now. Tested powerpc64le-linux. Pushed to trunk. -- >8 -- The _Std_pair concept uses in handles const qualified pairs, but not volatile qualified. That's because it just uses __is_pair which is specialize

[committed] libstdc++: Implement constexpr std::to_chars for C++23 (P2291R3)

This has been approved for C++23. I've just realised that the commit msg doesn't match the actual patch. I had a consteval lambda in an earlier version, but I changed it to do: +#if __cpp_lib_constexpr_charconv + if (std::__is_constant_evaluated()) + return __table<_DecOnly>.__d

Re: libstdc++: Address '-Wunused-function' for 'print_raw' (was: [committed] libstdc++: Simplify print_raw function for debug assertions)

On Sat, 15 Oct 2022 at 14:30, Jonathan Wakely wrote: > > On Sat, 15 Oct 2022 at 11:52, Thomas Schwinge wrote: > > > > Hi! > > > > On 2022-10-14T15:36:02+0100, Jonathan Wakely via Gcc-patches > > wrote: > > > Tested powerpc64le-linux. Pushed to tr

Re: [committed] libstdc++: Implement constexpr std::to_chars for C++23 (P2291R3)

On Sat, 15 Oct 2022 at 21:26, Jonathan Wakely via Libstdc++ wrote: > > libstdc++-v3/ChangeLog: > > * include/bits/charconv.h (__to_chars_10_impl): Add constexpr > for C++23. Remove 'static' from array. > * include/std/charconv (__cpp_lib_constexpr_charconv): Define. I mana

Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t

On Sun, 16 Oct 2022 at 11:23, Jakub Jelinek wrote: > > Hi! > > As the __bf16 support is now in at least on x86_64/i686, I've > updated my patch to cover bfloat16_t as well and implemented almost > everything for - the only thing missing I'm aware of is > std::nextafter std::float16_t and std::bfl

Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t

On Mon, 17 Oct 2022 at 22:33, Joseph Myers wrote: > > On Mon, 17 Oct 2022, Jonathan Wakely via Gcc-patches wrote: > > > > And I/O etc. support is missing, not sure I'm able to handle that and if > > > it > > > is e.g. possible to keep that su

Re: [PATCH] libstdc++, v3: Partial library support for std::float{16,32,64,128}_t and std::bfloat16_t

On Mon, 17 Oct 2022 at 17:26, Jakub Jelinek wrote: > > Hi! > > On Mon, Oct 17, 2022 at 02:07:00PM +0100, Jonathan Wakely wrote: > > Yes, that's now https://cplusplus.github.io/LWG/issue3790 > > The current proposed resolution is to just restore the C++20 functions > > and not provide anything for

[ping] [wwwdocs] Add reference to pp_format to Coding Conventions

ping... On 21/09/22 10:39 +0100, Jonathan Wakely wrote: Finding the docs for the GCC-specific diagnostic formats isn't easy. This might help. OK for wwwdocs? -- >8 -- htdocs/codingconventions.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/htdocs/codingconventions

Re: [PATCH] libstdc++: Implement ranges::stride_view from P1899R3

On Mon, 17 Oct 2022 at 21:09, Patrick Palka via Libstdc++ wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK, thanks. > > libstdc++-v3/ChangeLog: > > * include/std/ranges (stride_view): Define. > (stride_view::_Iterator): Define. > (views::__detail:

Re: [PATCH] libstdc++-v3: Implement {, b}float16_t nextafter and some fixes [PR106652]

On Wed, 19 Oct 2022 at 09:23, Jakub Jelinek wrote: > > Hi! > > The following patch implements nextafter for std::{,b}float16_t, > though right now only without constexpr support, and adds a testcase for it. > The testcase unfortunately relevealed I've screwed up testing of my last > patch. I've te

Re: [PATCH] libstdc++: Fix typo in stride_view's operator- [PR107313]

On Wed, 19 Oct 2022 at 15:33, Patrick Palka via Libstdc++ wrote: > > PR libstdc++/107313 OK > > libstdc++-v3/ChangeLog: > > * include/std/ranges (stride_view::_Iterator::operator-): Fix typo. > * testsuite/std/ranges/adaptors/stride/1.cc (test03): New test. > --- > libs

Re: [PATCH] libstdc++: Implement P2474R2 changes to views::take/drop

On Wed, 19 Oct 2022, 17:47 Patrick Palka via Libstdc++, < libstd...@gcc.gnu.org> wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > OK > libstdc++-v3/ChangeLog: > > * include/std/ranges (views::__detail::__is_repeat_view): Define > and later define a partial

Re: [PATCH] libstdc++: Redefine __from_chars_alnum_to_val's table

On Mon, 17 Oct 2022 at 17:27, Patrick Palka via Libstdc++ wrote: > > It looks like the constexpr commit r13-3313-g378a0f1840e694 > caused some modules regressions: > > FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2b (test for excess errors) > FAIL: g++.dg/modules/xtreme-header_b.C -std=c+

Re: [PATCH] libstdc++: Don't use gstdint.h anymore

On Thu, 20 Oct 2022 at 13:58, Arsen Arsenović via Libstdc++ wrote: > > libstdc++-v3/ChangeLog: > > * configure.ac: Stop generating gstdint.h. > * src/c++11/compatibility-atomic-c++0x.cc: Stop using gstdint.h. > --- > Tested on x86_64-pc-linux-gnu. > > libstdc++-v3/configure.ac

[committed] libstdc++: Fix std::move_only_function for incomplete parameter types

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- The std::move_only_function::__param_t alias template attempts to optimize argument passing for the invoker, by passing by rvalue reference for types that are non-trivial or large. However, the precondition for is_trivally_copyable makes it unsu

Re: [PATCH] libstdc++: respect with-{headers, newlib} for default hosted value

Pushed to trunk, thanks. On Wed, 12 Oct 2022 at 20:48, Arsen Arsenović via Libstdc++ wrote: > > This saves us a build flag when building for freestanding targets. > > libstdc++-v3/ChangeLog: > > * acinclude.m4: Default hosted to off if building without > headers and without newlib

Re: Adding a new thread model to GCC

How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one of them for GCC 13, but I don't know Windows well enough to determine which is better. On Sat, 1 Oct 2022 at 19:35, LIU Hao via Libstdc++ wrote:

Re: Adding a new thread model to GCC

On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++ wrote: > > On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: > > How does this compare with Eric B's proposal at > > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? > > > > It would be good if we can accept one of th

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On Mon, 24 Oct 2022 at 18:30, Jason Merrill wrote: > > On 10/21/22 19:28, Marek Polacek wrote: > > When testing a previous version of the patch, there were many FAILs in > > libstdc++'s 22_locale/; all of them because the warning triggered on > > > >const test_type& obj = std::use_facet(std::lo

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On Sat, 22 Oct 2022 at 00:28, Marek Polacek wrote: > I've run the testsuite/bootstrap with the warning enabled by default. > There were just a few FAILs: > * g++.dg/warn/Wdangling-pointer-2.C > * 20_util/any/misc/any_cast.cc > * 20_util/forward/c_neg.cc > * 20_util/forward/f_neg.cc These two are X

[committed] libstdc++: Fix allocator propagation in regex algorithms [PR107376]

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- The PR points out that we assume the match_results allocator is default constuctible, which might not be true. We also have a related issue with unwanted propagation from an object that might have an unequal allocator. Ideally we use the same a

Re: [PATCH v2] libstdc++: Don't use gstdint.h anymore

On 20/10/22 16:20 +0200, Arsen Arsenović wrote: libstdc++-v3/ChangeLog: * configure.ac: Stop generating gstdint.h. * src/c++11/compatibility-atomic-c++0x.cc: Stop using gstdint.h. --- > +using guintptr_t = __UINTPTR_TYPE__; I think this should be local in the only function tha

Re: [PATCH] libstdc++: Make placeholders inline when inline variables are available

On 20/10/22 16:58 +0200, Arsen Arsenović wrote: This slightly lowers the dependency of generated code on libstdc++.so. Looks good, I'll test and push, thanks. libstdc++-v3/ChangeLog: * include/std/functional: Make placeholders inline, if possible. --- libstdc++-v3/include/std/functio

[committed] libstdc++: Fix dangling reference in filesystem::path::filename()

Tested powerpc64le-linux. Pushed to trunk. Worth backporting too. -- >8 -- The new -Wdangling-reference warning noticed this. libstdc++-v3/ChangeLog: * include/bits/fs_path.h (path::filename()): Fix dangling reference. --- libstdc++-v3/include/bits/fs_path.h | 6 +++--- 1 file

Re: [PATCH] libstdc++: Small extended float support tweaks

On Fri, 21 Oct 2022 at 08:29, Jakub Jelinek wrote: > > Hi! > > The following patch isn't for immediate commit, as it has several > dependencies, in particular: > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604080.html

Re: [PATCH] libstdc++-v3: support for extended floating point types

On Fri, 21 Oct 2022 at 16:58, Jakub Jelinek wrote: > > Hi! > > The following patch adds support for extended floating point > types. > C++23 removes the float/double/long double specializations from the spec > and instead adds explicit(bool) specifier on the converting constructor. > The patch us

Re: [committed] libstdc++: Fix compare_exchange_padding.cc test for std::atomic_ref

On Mon, 31 Oct 2022 at 15:34, Eric Botcazou wrote: > > > The test was only failing for me with -m32 (and not -m64), so I didn't > > notice until now. That probably means we should make the test fail more > > reliably if the padding isn't being cleared. > > The tests fail randomly for me on SPARC64

Re: [PATCH] libstdc++-v3: support for extended floating point types

On Mon, 31 Oct 2022 at 16:57, Jakub Jelinek wrote: > > On Mon, Oct 31, 2022 at 10:26:11AM +, Jonathan Wakely wrote: > > > --- libstdc++-v3/include/std/complex.jj 2022-10-21 08:55:43.037675332 > > > +0200 > > > +++ libstdc++-v3/include/std/complex2022-10-21 17:05:36.802243229 > > > +0200

Re: [committed] libstdc++: Fix compare_exchange_padding.cc test for std::atomic_ref

On Mon, 31 Oct 2022 at 17:03, Eric Botcazou wrote: > > > I suppose we could use memcmp on the as variable itself, to inspect > > the actual stored padding rather than the returned copy of it. > > Yes, that's probably the only safe stance when optimization is enabled. Strictly speaking, it's not

<    7   8   9   10   11   12   13   14   15   16   >