Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

On 3/25/24 13:07, Jakub Jelinek wrote: On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote: This started to break $ cat test.cc struct S1 { S1(); }; struct S2 { S2() {} S1 a[1] {}; }; $ g++ -fsyntax-only test.cc test.cc: In constructor ‘S2::S2()’: test.cc:3:10: error

Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

On 3/21/24 10:28 PM, Jason Merrill wrote: On 3/21/24 16:48, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. This started to break $ cat test.cc struct S1 { S1(); }; struct S2 { S2() {} S1 a[1] {}; }; $ g++ -fsyntax-only test.cc test.cc: In

Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior

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, $ cat test.cc #include #include void f(std::vector , void const * p) { std::erase(v, p); } $ ~/gcc/inst/bin/g++ -std=c++20 -D_GLIBCXX_DEBUG

Re: [committed] libstdc++: Define std::numeric_limits<_FloatNN> before C++23

On 8/17/23 22:32, Jonathan Wakely via Libstdc++ wrote: Tested x86_64-linux. Pushed to trunk. -- >8 -- The extended floating-point types such as _Float32 are supported by GCC prior to C++23, you just can't use the standard-conforming names from to refer to them. This change defines the

Re: [pushed] c++: avoid initializer_list [PR105838]

On 12/8/22 19:41, Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu, applying to trunk. Bisecting shows this started to break $ cat test.cc #include template struct ConstCharArrayDetector; template struct ConstCharArrayDetector { using Type = int; }; struct OUString {

Re: [pushed] c++: build initializer_list in a loop [PR105838]

On 08/12/2022 19:45, Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu, applying to trunk. Bisecting shows this started to break $ cat test.cc #include template struct ConstCharArrayDetector; template struct ConstCharArrayDetector { using Type = int; }; struct OUString {

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

On 12/12/2022 12:18, Jonathan Wakely wrote: If Clang already treats __is_signed as a conditionally-active built-in, it should do the same for __is_unsigned. Wasn't aware of that special handling of __is_signed. Filed "Also allow __is_unsigned to be used as

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: + static constexpr bool __is_unsigned + = __and_v, + is_unsigned>; Using `__is_unsigned` as an identifier here causes compilation issues with Clang, which predefines that as a builtin predicate.

Re: [PATCH (pushed)] sphinx: fix building if sphinx-build is missing

On 11/13/22 20:26, Martin Liška wrote: The patch is fine, please send it to gcc-patches ML and install it. I sent a patch now, but don't have commit rights.

[PATCH] sphinx: more build fixing if sphinx-build is missing

...similar to 1f9c79367e136e0ca5b775562e6111e1a0d0046f "sphinx: fix building if sphinx-build is missing" gcc/ChangeLog: * fortran/Make-lang.in: Build info pages conditionally. --- gcc/fortran/Make-lang.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

On 11/12/22 03:47, Jonathan Wakely wrote: On Fri, 11 Nov 2022 at 21:00, Stephan Bergmann wrote: On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote: As discussed in the PR, this makes it three times faster to construct iostreams objects. Tested x86_64-linux. Pushed to trunk. I

Re: [PATCH (pushed)] sphinx: fix building if sphinx-build is missing

On 11/9/22 10:09, Martin Liška wrote: I noticed I modified Makefile.in files in the Sphinx series. While I was supposed to modifiky Makefile.am and use automake. I'm going to fix that soon. A recent master build against (apparently too old) python3-sphinx-5.0.2-2.fc37.noarch failed for me

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote: As discussed in the PR, this makes it three times faster to construct iostreams objects. Tested x86_64-linux. Pushed to trunk. I haven't yet tried to track down what's going on, but with various versions of Clang (e.g.

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

On 19/09/2022 17:33, Thomas Neumann wrote: Can you try if the patch below fixes the problem? It keeps the data structures alive at shutdown, though, which will probably make some leak detectors unhappy. Alternatively we could simply remove the gcc_assert (ob) in line 285 of that file. As far

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

On 19/09/2022 15:55, Thomas Neumann wrote: Apparently a registered frame is not found when deregistering, which triggers an assert. I will debug this. Could you send me a script or a description on how to reproduce the issue? Thanks a lot! I'm in the process of checking whether a more

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

On 16/09/2022 12:19, Thomas Neumann via Gcc-patches wrote: The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is

Re: [PATCH] c++: Extend -Wpessimizing-move to other contexts

On 16/08/2022 14:27, Marek Polacek via Gcc-patches wrote: Ping. (The other std::move patches depend on this one.) "c++: Extend -Wpessimizing-move to other contexts" started to cause false positive $

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote: Yeah, I guess so. But I've already pushed the patch. This commit obviously breaks using libstdc++ with Clang (in -std=c++2b mode), which doesn't implement those new builtins. Something like the below would fix that, diff --git

Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

On 01/07/2022 22:30, Stephan Bergmann wrote: On 6/25/22 00:26, Jason Merrill via Gcc-patches wrote: This seems like a good warning to have in -Wall, as requested.  But as pointed out in PR20423, some users want a warning only when a derived function doesn't override any base function.  So let's

Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

On 6/25/22 00:26, Jason Merrill via Gcc-patches wrote: This seems like a good warning to have in -Wall, as requested. But as pointed out in PR20423, some users want a warning only when a derived function doesn't override any base function. So let's put that lesser version in -Wall (and

Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]

On 17/01/2022 20:14, Martin Sebor wrote: I tried to set up OpenOffice for testing with the latest GCC but couldn't get the build to finish (it failed downloading some unavailable prerequisites).  I don't remember what problem I ran into with LibreOffice; it was before I upgraded to Fedora 35

Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]

On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote: Last ping for this stage 1 feature before stage 3 ends: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html This hits somewhat unexpectedly at (test case reduced from a hit in LibreOffice) $ cat test.cc #include

Re: [PATCH] libstdc++: Implement C++20 atomic and atomic

On 1/17/22 01:12, Jonathan Wakely via Libstdc++ wrote: Here's the finished version of that patch, which is all inline in the header, and performs faster too. Tested powerpc64le-linux and x86_64-linux. Pushed to trunk. FYI, recent Clang still requires typename in two places to compile with

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On 14/01/2022 14:28, Marek Polacek wrote: On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote: On 30/11/2021 16:27, Marek Polacek wrote: I guess we were concerned with programs that generate other programs. Maybe UCNs should be ignored by default. There's still time to adjust

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On 30/11/2021 16:27, Marek Polacek wrote: I guess we were concerned with programs that generate other programs. Maybe UCNs should be ignored by default. There's still time to adjust the behavior. Is there any update on this? Shall I file a bug? As-is, -Wbidi-chars is unusable for building

Re: [committed] libstdc++: Reduce template instantiations in

On 05/01/2022 14:47, Jonathan Wakely via Libstdc++ wrote: Tested powerpc64le-linux, pushed to trunk. This moves the last two template parameters of __regex_algo_impl to be runtime function parameters instead, so that we don't need four different instantiations for the possible ways to call it.

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On 30/11/2021 14:26, Marek Polacek wrote: On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote: On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote: On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: Ping, can we conclude on the name? IMHO, -Wbidirectional

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote: On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine, but changing the name is a trivial operation. Here's a patch with a better name (suggested by

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

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 undefined

Re: trunk -D_GLIBCXX_DEBUG #include fails

On 09/08/2021 16:42, Jonathan Wakely via Gcc-patches wrote: This is what I'm testing. Thanks, that worked fine for my build of LibreOffice.

trunk -D_GLIBCXX_DEBUG #include fails

Not sure why I started to experience this now with a recent GCC/libstdc++ trunk build: $ cat test.cc #include $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401,

Re: [committed] libstdc++: Use __libc_single_threaded for locale initialization

On 24/11/2020 15:59, Jonathan Wakely via Gcc-patches wrote: Most initialization of locales and facets happens before main() during startup, when the program is likely to only have one thread. By using the new __gnu_cxx::__is_single_threaded() function instead of checking __gthread_active_p() we

Re: [PATCH] libstdc++: Add C++2a synchronization support

On 20/11/2020 23:44, Thomas Rodgers wrote: Tested x86_64-pc-linux-gnu, committed. ...and there are multiple definition complaints from the linker because of two missing "include": index 7b2682a577e..23ab2018ca8 100644 --- a/libstdc++-v3/include/bits/atomic_wait.h +++

Re: [PATCH] libstdc++: Add C++2a synchronization support

On 20/11/2020 23:44, Thomas Rodgers wrote: Tested x86_64-pc-linux-gnu, committed. Clang complains: $ cat test.cc #include $ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc In file included from test.cc:1: In file included from

Re: [PATCH] libstdc++: Implement C++20 features for

On 07/10/2020 18:55, Thomas Rodgers wrote: From: Thomas Rodgers New ctors and ::view() accessor for - * basic_stingbuf * basic_istringstream * basic_ostringstream * basic_stringstreamm New ::get_allocator() accessor for basic_stringbuf. I found that this

Re: [committed] libstdc++: Allow Lemire's algorithm to be used in more cases

On 03/11/2020 23:25, Jonathan Wakely wrote: On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote: On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote: This extends the fast path to also work when the URBG's range of possible values is not the entire range of its result_type

Re: [committed] libstdc++: Allow Lemire's algorithm to be used in more cases

On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote: This extends the fast path to also work when the URBG's range of possible values is not the entire range of its result_type. Previously, the slow path would be used for engines with a uint_fast32_t result type if that type is actually a

Re: [committed] libstdc++: Simplify std::shared_ptr construction from std::weak_ptr

On 21/10/2020 22:14, Jonathan Wakely via Gcc-patches wrote: The _M_add_ref_lock() and _M_add_ref_lock_nothrow() members of _Sp_counted_base are very similar, except that the former throws an exception when the use count is zero and the latter returns false. The former (and its callers) can be

Re: [PATCH] libstdc++: Diagnose visitors with different return types [PR95904]

On 08/10/2020 16:27, Jonathan Wakely via Gcc-patches wrote: On 05/10/20 22:35 +0300, Ville Voutilainen via Libstdc++ wrote: On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen wrote: The patch is borked, doesn't pass tests, fixing... Unborked, ok for trunk if full testsuite passes? Assuming it

Re: [PATCH] c++: Fix up default initialization with consteval default ctor [PR96994]

On 15/09/2020 09:57, Jakub Jelinek via Gcc-patches wrote: The following testcase is miscompiled (in particular the a and i initialization). The problem is that build_special_member_call due to the immediate constructors (but not evaluated in constant expression mode) doesn't create a CALL_EXPR,

Re: [PATCH] libstdc++: P0769R2 Add shift to

On 21/02/2020 20:29, Patrick Palka wrote: diff --git a/libstdc++-v3/include/bits/ranges_algo.h b/libstdc++-v3/include/bits/ranges_algo.h index 7de1072abf0..c36afc6e19b 100644 --- a/libstdc++-v3/include/bits/ranges_algo.h +++ b/libstdc++-v3/include/bits/ranges_algo.h @@ -3683,6 +3683,54 @@

Re: [PATCH] avoid issuing -Wredundant-tags in shared C/C++ code in headers (PR 93804)

On 19/02/2020 01:02, Martin Sebor wrote: PR 93804 points out that issuing -Wredundant-tags for declarations in C headers included in C++ isn't helpful because the tags cannot be removed without breaking C programs that depend on the headers. Attached is a patch that avoids the warning in these

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

On 18/02/2020 12:56, Jonathan Wakely wrote: Does this solve the problem, and work with both compilers? diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges index b9ac528fdff..481ba75ee5e 100644 --- a/libstdc++-v3/include/std/ranges +++

Re: [PATCH] add -Wmismatched-tags (PR 61339)

On 03/12/2019 22:49, Martin Sebor wrote: I added another warning: -Wredundant-tags to point out instances where the class-key or enum-key can safely be dropped. Both warnings are off by default. I think -Wredundant-tags would be more useful if it did not warn about occurrences within extern

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

On 18/02/2020 02:20, Patrick Palka wrote: On Mon, 17 Feb 2020, Stephan Bergmann wrote: On 04/02/2020 03:07, Patrick Palka wrote: This patch implements [range.adaptors]. It also includes the changes from P3280 and P3278 and P3323, without which many standard examples won't work. I see

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

On 04/02/2020 03:07, Patrick Palka wrote: This patch implements [range.adaptors]. It also includes the changes from P3280 and P3278 and P3323, without which many standard examples won't work. I see that with this

Re: [PATCH] libstdc++: Define std::lexicographical_compare_three_way for C++20

On 05/12/2019 13:46, Jonathan Wakely wrote: commit 5012548fd62526fdf5e04aeacee2b127efbac0e0 Author: Jonathan Wakely Date: Thu Dec 5 12:23:53 2019 + libstdc++: Define std::lexicographical_compare_three_way for C++20 * include/bits/stl_algobase.h

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

On 26/11/2019 20:07, François Dumont wrote: However I wasn't sure about this syntax before the commit so I had run the new 2_neg.cc with: make CXXFLAGS=-std=c++98 check-debug and it worked fine and still is ! I also try -std=gnu++98 and made sure that pch had been updated by re-building

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

On 22/11/2019 18:59, Jonathan Wakely wrote: On 22/11/19 18:38 +0100, François Dumont wrote:     I noticed that we are not checking that iterators are not singular in valid_range. Moreover __check_singular signature for pointers is not intercepting all kind of pointers in terms of

Re: [PATCH] libstdc++: Define C++20 range utilities and range factories

On 17/11/2019 02:07, Jonathan Wakely wrote: This adds another chunk of the header. The changes from P1456R1 (Move-only views) and P1862R1 (Range adaptors for non-copyable iterators) are included, but not the changes from P1870R1 (forwarding-range is too subtle). The tests for subrange and

Re: [PATCH] PR c++/91369 Implement P0784R7 changes to allocation and construction

On 23/10/2019 21:27, Jonathan Wakely wrote: This patch is the first part of library support for constexpr std::vector and std::string. This only includes the changes to std::allocator, std::allocator_traits, std::construct_at, std::destroy_at, std::destroy and std::destroy_n. [...] Tested

[WIP PATCH] PR71102: Make #pragma GCC error/warning concat strings

(I think this is my first patch submission here, so please bear with me.) As discussed at "_Pragma("GCC warning ...") should concatenate string literals", it would be useful if #pragma GCC error/warning behaved like #pragma message and

Re: PR libstdc++/90945 Patch to have pretty printer for std::vector return bool intead of int for elements

On 19/06/2019 21:54, Jonathan Wakely wrote: On 19/06/19 21:49 +0200, Michael Weghorn wrote: On 19/06/2019 21.37, Jonathan Wakely wrote: +  std::vector vb; +  vb.reserve(100); +  vb.push_back(true); +  vb.push_back(true); +  vb.push_back(false); +  vb.push_back(false); +  vb.push_back(true); + 

Re: [PATCH] Define std::__invoke_r for INVOKE

On 14/05/2019 17:25, Jonathan Wakely wrote: * include/bits/invoke.h (__invoke_r): Define new function implementing the INVOKE pseudo-function. * testsuite/20_util/function_objects/invoke/1.cc: Add more tests. * testsuite/20_util/function_objects/invoke/2.cc: New test. Tested

Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap

On 03/05/2019 00:30, Jonathan Wakely wrote: On 02/05/19 21:33 +0100, Jonathan Wakely wrote: This was also reported as https://gcc.gnu.org/PR90314 And here's what I've tested and committed. Thanks, that fixes things for me.

Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap

On 29/04/2019 15:26, Jonathan Wakely wrote: * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use _GLIBCXX_NOEXCEPT_IF to simplify declarations. This just avoids having to repeat the name and parameter-list of the functions. libstdc++-v3/include/std/type_traits still

Documentation: -gsplit-dwarf missing from Option Summary

Cannot identify what sorting is used for that list (if any), so putting it at the end (and -gsplit-dwarf also follows -fvar-tracking-assignments in the "Options for Debugging Your Program" section). Author: Stephan Bergmann Date: Tue Jun 26 15:04:54 2018 +0200 Documentatio

Re: [PATCH] Default special members of regex types and add noexcept

On 08/06/18 13:01, Jonathan Wakely wrote: Nothing very exciting, just adding noexcept and defaulting some members. * include/bits/regex.h (sub_match): Add noexcept to default constructor and length observer. (match_results): Add noexcept to default constructor and observers

[PATCH] Missing noexcept in string_view::find_first_of declaration

>From 0a75fbb0c16e216892d16f1ba3448471e33f61bb Mon Sep 17 00:00:00 2001 From: Stephan Bergmann <sberg...@redhat.com> Date: Fri, 24 Nov 2017 18:04:30 +0100 Subject: [PATCH] Missing noexcept in string_view::find_first_of declaration cf. definition in libstdc++-v3/include/bits/string

[PATCH] Fix typo in unordered_map deduction guide, missing "typename ="

+/8.0.0/bits/unordered_map.h:1196:34: note: non-deducible template parameter (anonymous) _RequireAllocator<_Allocator>> ^ 1 error generated. >From 0ecb03c59b9318b3f47e49daa2f45dd513035d55 Mon Sep 17 00:00:00 2001 From: Stephan Bergm

Re: [PATCH] PR libstdc++/80624 satisfy invariant for char_traits::eof()

On 05/05/2017 07:05 PM, Jonathan Wakely wrote: As discussed at http://stackoverflow.com/q/43769773/981959 (and kinda hinted at by http://wg21.link/lwg1200) there's a problem with char_traits::eof() because it returns int_type(-1) which is the same value as u'\u', a valid UTF-16 code point.

Re: [PATCH] missing return in debug/vector _Safe_vector::operator=

On 04/28/2015 02:38 PM, Jonathan Wakely wrote: [CCing gcc-patches] On 28/04/15 14:32 +0200, Stephan Bergmann wrote: broken on GCC 5 and trunk Ouch. OK for trunk and the branch, do you have commit privs? No, I don't; would be great if you can push that.