[Bug libstdc++/122134] New: flat_set Mandates is_nothrow_swappable_v

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122134 Bug ID: 122134 Summary: flat_set Mandates is_nothrow_swappable_v Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc

[Bug libstdc++/122099] New: ranges::sample requires std::uniform_random_bit_generator to have result_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122099 Bug ID: 122099 Summary: ranges::sample requires std::uniform_random_bit_generator to have result_type Product: gcc Version: 15.0 Status: UNCONFIRMED Severity:

[Bug libstdc++/122062] piecewise_linear_distribution(InputIteratorB, InputIteratorB, InputIteratorW) invokes comma operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122062 --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > --- a/libstdc++-v3/include/bits/random.tcc > +++ b/libstdc++-v3/include/bits/random.tcc > @@ -83,7 +83,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >__normalize(_InputI

[Bug libstdc++/122062] New: piecewise_linear_distribution(InputIteratorB, InputIteratorB, InputIteratorW) invokes comma operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122062 Bug ID: 122062 Summary: piecewise_linear_distribution(InputIteratorB, InputIteratorB, InputIteratorW) invokes comma operator Product: gcc Version: 15.0

[Bug libstdc++/121940] function_ref CTAD is not SFINAE friendly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121940 --- Comment #5 from 康桓瑋 --- (In reply to Tomasz Kamiński from comment #4) > Fixed for v16. Thanks for the quick fix. But I still don't seem to be subscribed to the libstdc++ mailing list. Do you know who approved this permission? I've already

[Bug c++/122043] New: ICE: in type_dependent_expression_p, at cp/pt.cc:29600

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122043 Bug ID: 122043 Summary: ICE: in type_dependent_expression_p, at cp/pt.cc:29600 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug libstdc++/122032] The size of bind_front/bind_back(...) is not optimized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122032 --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > Please consider subscribing to the libstdc++ mailing list and making these > observations *before* the patches are committed to git. I tried to subscribe, but it seems

[Bug libstdc++/122032] New: The size of bind_front/bind_back(...) is not optimized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122032 Bug ID: 122032 Summary: The size of bind_front/bind_back(...) is not optimized Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priori

[Bug libstdc++/122022] New: bind_front/bind_back/not_fn pass function parameters by value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122022 Bug ID: 122022 Summary: bind_front/bind_back/not_fn pass function parameters by value Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/121956] P2165R4: Compatibility between tuple and tuple-like objects is not fully implemented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956 --- Comment #4 from 康桓瑋 --- (In reply to Andrew Pinski from comment #2) > Note I don't think P2165R4 applies here. > Because that just required: > ``` > static_assert( > std::is_constructible_v< > std::ranges::range_value_t, >

[Bug libstdc++/121956] P2165R4: Compatibility between tuple and tuple-like objects is not fully implemented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956 --- Comment #1 from 康桓瑋 --- The original PR113309 was tagged RESOLVED FIXED.

[Bug libstdc++/121956] New: P2165R4: Compatibility between tuple and tuple-like objects is not fully implemented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121956 Bug ID: 121956 Summary: P2165R4: Compatibility between tuple and tuple-like objects is not fully implemented Product: gcc Version: 15.0 Status: UNCONFIRMED Sev

[Bug libstdc++/121913] ranges::rotate should use ranges::iter_move

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #5 from 康桓瑋

[Bug libstdc++/121940] function_ref CTAD is not SFINAE friendly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121940 --- Comment #1 from 康桓瑋 --- Other testcase: #include struct S { int x; }; int main() { int y; std::function_ref fr(std::nontype<&S::x>, y); } https://godbolt.org/z/6sEM1bocK

[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 --- Comment #5 from 康桓瑋 --- It seems that ranges::push_heap has the same issue, since ranges::iter_move(ranges::prev(__last)) may not necessarily be able to *implicitly* construct iter_value_t<_Iter>.

[Bug libstdc++/119820] Formatting ranges make a subrange via ranges::subrange (__first, __first + __n)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820 --- Comment #3 from 康桓瑋 --- Just for the record, the latest ranges::shuffle has similar issues: https://godbolt.org/z/hrjE4deGh

[Bug libstdc++/121940] New: function_ref CTAD is not SFINAE friendly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121940 Bug ID: 121940 Summary: function_ref CTAD is not SFINAE friendly Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc

[Bug libstdc++/121782] Missing Mandates for operator() of std::boyer_moore_[horspool]_searcher

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121782 --- Comment #2 from 康桓瑋 --- Fixed by https://github.com/gcc-mirror/gcc/commit/a559f1423cd72c40a9467429f0fcb14435bf7dcf I think.

[Bug c++/121859] New: ICE: in set_diagnostic_buffer, at buffering.cc:49

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121859 Bug ID: 121859 Summary: ICE: in set_diagnostic_buffer, at buffering.cc:49 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug libstdc++/121858] function_ref(nontype_t<__fn>, _Up&& __ref) did not consider that _Up is a reference_wrapper

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121858 --- Comment #3 from 康桓瑋 --- (In reply to 康桓瑋 from comment #2) > I know it's kind of weird that rvalue reference_wrappers is not supported > ​​in this case, i.e. std::function_ref fr(std::nontype<&S::f>, > std::ref(s)) is ill-formed. But that's w

[Bug libstdc++/121858] function_ref(nontype_t<__fn>, _Up&& __ref) did not consider that _Up is a reference_wrapper

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121858 --- Comment #2 from 康桓瑋 --- I know it's kind of weird that rvalue reference_wrappers is not supported ​​in this case, i.e. std::function_ref fr(std::nontype<&S::f>, std::ref(s)) is ill-formed. But that's what the current standard says.

[Bug libstdc++/121858] function_ref(nontype_t<__fn>, _Up&& __ref) did not consider that _Up is a reference_wrapper

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121858 --- Comment #1 from 康桓瑋 --- (In reply to 康桓瑋 from comment #0) > This constructor invokes the member pointer on a pointer to object _Up when > _Fn is a member pointer. > > However, _Up can be a std::reference_wrapper because std::invoke supports

[Bug libstdc++/121858] New: function_ref(nontype_t<__fn>, _Up&& __ref) did not consider that _Up is a reference_wrapper

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121858 Bug ID: 121858 Summary: function_ref(nontype_t<__fn>, _Up&& __ref) did not consider that _Up is a reference_wrapper Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug c++/121808] New: ICE: in import_module, at cp/module.cc:21743

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121808 Bug ID: 121808 Summary: ICE: in import_module, at cp/module.cc:21743 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/121804] join_view::iterator::_M_get_inner should be noexcept

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121804 --- Comment #1 from 康桓瑋 --- 👍 Hewill Kang透過 Gmail 回應

[Bug libstdc++/121804] New: join_view::iterator::_M_get_inner should be noexcept

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121804 Bug ID: 121804 Summary: join_view::iterator::_M_get_inner should be noexcept Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compon

[Bug libstdc++/121782] New: Missing Mandates for operator() of boyer_moore_searcher and boyer_moore_horspool_searcher

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121782 Bug ID: 121782 Summary: Missing Mandates for operator() of boyer_moore_searcher and boyer_moore_horspool_searcher Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug libstdc++/121745] New: The return of get(pair<_Up, _Tp>&& __p) may be ill-formed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121745 Bug ID: 121745 Summary: The return of get(pair<_Up, _Tp>&& __p) may be ill-formed Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Pri

[Bug libstdc++/121245] __any_input_iterator should not accept C++20 input_iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121245 --- Comment #3 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > I thought that too about _InputIterator constraints, but it seems it's > allowed by [container.reqmnts]/69: > > The behavior of certain container member functions and

[Bug libstdc++/121245] New: __any_input_iterator should not support C++20 input_iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121245 Bug ID: 121245 Summary: __any_input_iterator should not support C++20 input_iterator Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/121196] New: std::erase for inplace_vector missing default template parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121196 Bug ID: 121196 Summary: std::erase for inplace_vector missing default template parameter Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/121142] warning "potential null pointer dereference" raised when using generator with -O1 -Wnull-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121142 --- Comment #1 from 康桓瑋 --- Not sure if it has anything to do with PR 105580.

[Bug c++/121142] New: warning "potential null pointer dereference" raised when using generator with -O1 -Wnull-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121142 Bug ID: 121142 Summary: warning "potential null pointer dereference" raised when using generator with -O1 -Wnull-dereference Product: gcc Version: 15.0 Status: UNCONFIRM

[Bug c++/121125] New: ICE: canonical types differ for identical types 'auto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121125 Bug ID: 121125 Summary: ICE: canonical types differ for identical types 'auto Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug libstdc++/105611] std::shift_left/right should not use ranges::next

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611 --- Comment #2 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > std::shift_left/right require a Cpp17ForwardIterator, but here I is not > default constructible which seems like a constraint violation making the > testcase invalid? > >

[Bug libstdc++/112641] : `drop_view::begin const` has O(n) complexity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641 --- Comment #7 from 康桓瑋 --- (In reply to Patrick Palka from comment #6) > Fixed for 15 / 14.3 / 13.4 But you didn't *optimize* the non-const begin, right?

[Bug libstdc++/120789] ranges::unique should use ranges​::​iter_move

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120789 --- Comment #1 from 康桓瑋 --- Same goes for ranges::remove_if: std::ranges::subrange r; auto [begin, end] = std::ranges::remove_if(r, [](auto&&) { return true; }); https://godbolt.org/z/Trb13x8fa

[Bug libstdc++/120789] New: ranges::unique should use ranges​::​iter_move

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120789 Bug ID: 120789 Summary: ranges::unique should use ranges​::​iter_move Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: li

[Bug libstdc++/119962] : __maybe_present_t misses initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119962 --- Comment #4 from 康桓瑋 --- (In reply to Andrew Pinski from comment #2) > https://eel.is/c++draft/range.lazy.split.outer > > > Testcase from godbolt: > ``` > #include > > struct I { > int x; > using difference_type = std::ptrdiff_t; >

[Bug libstdc++/119962] New: : __maybe_present_t misses initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119962 Bug ID: 119962 Summary: : __maybe_present_t misses initialization Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstd

[Bug libstdc++/109162] C++23 improvements to std::format

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #23 from 康桓瑋 --- (In reply to Tomasz Kamiński from comment #22) > > That is highly intentional to fix incorrect formatting when the container > > is a string. See https://cplusplus.github.io/LWG/issue3881 > > I am well aware of thi

[Bug libstdc++/109162] C++23 improvements to std::format

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #21 from 康桓瑋 --- > Furthermore the standard specifies these formatters as delegating to > formatter, charT>, which in turn > delegates to range_formatter. This patch avoids one level of indirection, > and dependency o

[Bug c++/119907] New: ICE in tsubst_expr, at cp/pt.cc:21973

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 Bug ID: 119907 Summary: ICE in tsubst_expr, at cp/pt.cc:21973 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/119906] New: error: '' in namespace 'std' does not name a type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119906 Bug ID: 119906 Summary: error: '' in namespace 'std' does not name a type Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P

[Bug libstdc++/119861] formatter specialization for map-like range has set_separator/set_brackets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119861 --- Comment #1 from 康桓瑋 --- ..which should not: #include struct Map { std::pair* begin(); std::pair* end(); }; template<> constexpr auto std::format_kind = std::range_format::map; int main() { std::formatter fmt; fmt.set_separator("

[Bug libstdc++/119861] New: formatter specialization of formatter for map class scope has set_separator/set_brackets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119861 Bug ID: 119861 Summary: formatter specialization of formatter for map class scope has set_separator/set_brackets Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug libstdc++/119820] Formatting ranges make a subrange via ranges::subrange (__first, __first + __n)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820 --- Comment #1 from 康桓瑋 --- An example I can think of could be: struct I { using difference_type = int; using value_type = char; value_type operator*() const; I& operator++(); I operator++(int); I& operator--(); I operator--(int);

[Bug libstdc++/119820] New: Formatting ranges make a subrange via ranges::subrange (__first, __first + __n)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820 Bug ID: 119820 Summary: Formatting ranges make a subrange via ranges::subrange (__first, __first + __n) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity

[Bug libstdc++/119752] New: ranges::find does not handle volatile char ranges well

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119752 Bug ID: 119752 Summary: ranges::find does not handle volatile char ranges well Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug libstdc++/119748] std::string::string(InputIterator, InputIterator) rejects volatile charT* as iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748 --- Comment #1 from 康桓瑋 --- The _S_copy_range(pointer __p, _Rg&& __rg, size_type __n) help committed yesterday also needs to be fixed for the contiguous_range branch.

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #26 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #25) > If we can't use range-based 'for' with ranges then we've taken a wrong turn > somewhere. > > I did test them in e.g. std/ranges/access/begin.cc so we know that > rang

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #24 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #22) > but they deserve to break. I agree with that.

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #21 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #20) > Does it matter? By design, ranges::begin does the same things as range-based > for (handles arrays first, then looks for member begin(), then looks for ADL > begin).

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #19 from 康桓瑋 --- (In reply to GCC Commits from comment #18) > The master branch has been updated by Jonathan Wakely : > > https://gcc.gnu.org/g:882d3b319dbf50ae64080731a1398031c100b7c7 > > commit r15-9378-g882d3b319dbf50ae64080731a

[Bug libstdc++/119721] New: tuple<> cannot be compared with array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119721 Bug ID: 119721 Summary: tuple<> cannot be compared with array Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug libstdc++/119620] flat_set::emplace is constrained, and always constructs element on the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620 --- Comment #5 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > (In reply to 康桓瑋 from comment #0) > > I don't know why the standard sometimes constrains emplace(), sometimes only > > constrains insert(), and sometimes constrains neit

[Bug libstdc++/119620] New: flat_set::emplace is constrained

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620 Bug ID: 119620 Summary: flat_set::emplace is constrained Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 --- Comment #11 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #10) > (In reply to 康桓瑋 from comment #9) > > Still need casting the return difference type from __mindist, I think? > > Ah yes, we need to cast it back to the type of the fi

[Bug libstdc++/119545] New: tuple::operator==()'s help lambda does not specify return type as bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119545 Bug ID: 119545 Summary: tuple::operator==()'s help lambda does not specify return type as bool Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/119516] New: SIGKILL when -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119516 Bug ID: 119516 Summary: SIGKILL when -O2 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassig

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587 --- Comment #9 from 康桓瑋 --- (In reply to GCC Commits from comment #8) > The master branch has been updated by Jonathan Wakely : > > https://gcc.gnu.org/g:f4b6acfc36fb1f72fdd5bf4da208515e6495a062 > > commit r15-8980-gf4b6acfc36fb1f72fdd5bf4da20

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #20 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #19) > We could do this, and rely on the fact that the number of aliases is always > small so that we can claim it's O(1): > > --- a/libstdc++-v3/include/std/text_encoding >

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #18 from 康桓瑋 --- > The random-access-non-sized ranges in the standard are currently only > infinite ranges such as views::iota(0). Random access is useful for these > ranges because we can random access any place without worrying abo

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #17 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #15) > (In reply to 康桓瑋 from comment #13) > > I'm not sure it's reasonable or trivial for alias_view to be sized_range, > > I don't think it is necessary. Is there a use cas

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #13 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #12) > Implementation-defined means the implementation must define it (and document > it). > > If the implementation says the types are different, then they're different, >

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #14 from 康桓瑋 --- I believe the correct way should be: else if constexpr (ranges::common_range<_Rg> && requires { requires derived_from>::iterator_category,

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #13 from 康桓瑋 --- (In reply to Tomasz Kamiński from comment #12) > I have realized that with the resolution of the > https://cplusplus.github.io/LWG/lwg-defects.html#3749, you can run into this > problem by doing: > > auto r = std::v

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #11 from 康桓瑋 --- > Use __cpp17_input_iterator can still produce hard errors in some edge cases. With "hard errors", I mean the following: struct I { using difference_type = int; using value_type = int; int operator*() const;

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #10 from 康桓瑋 --- (In reply to Tomasz Kamiński from comment #9) > > Hum, meeting Cpp17LegacyIterator requirements does not mean it is a C++17 > > input iterator, only iterator_traits::iterator_category represents its > > category, s

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #8 from 康桓瑋 --- (In reply to GCC Commits from comment #6) > The master branch has been updated by Tomasz Kaminski : > > https://gcc.gnu.org/g:4d1b19695669e6c67b9c3df07673bc22cae3a662 > > commit r15-8879-g4d1b19695669e6c67b9c3df0767

[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #5 from 康桓瑋 --- (In reply to Tomasz Kamiński from comment #4) > If want to support user-defined containers, I think we should check if > iterator_traits::iterator category exists, before calling > insert(Iterator, Iterator) overload.

[Bug c++/119434] New: template argument 2 is invalid for CTAD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119434 Bug ID: 119434 Summary: template argument 2 is invalid for CTAD Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/119427] New: std::erase_if(std::flat_map) does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427 Bug ID: 119427 Summary: std::erase_if(std::flat_map) does not work Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libst

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427 --- Comment #2 from 康桓瑋 --- Also, erase_if should not use ranges::remove_if, since that would support member pointers via std::invoke, which the standard currently disallows. This seems like an enhancement, though.

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427 --- Comment #1 from 康桓瑋 --- flat_set has the same issue.

[Bug libstdc++/119415] New: flat_set::insert_range may not handle C++20 common-range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 Bug ID: 119415 Summary: flat_set::insert_range may not handle C++20 common-range Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Prio

[Bug libstdc++/119358] New: _M_rehash_insert of unordered sets/maps misses casting of difference_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119358 Bug ID: 119358 Summary: _M_rehash_insert of unordered sets/maps misses casting of difference_type Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: norm

[Bug c++/119252] New: g++: internal compiler error: Segmentation fault signal terminated program cc1plus

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119252 Bug ID: 119252 Summary: g++: internal compiler error: Segmentation fault signal terminated program cc1plus Product: gcc Version: 15.0 Status: UNCONFIRMED Sever

[Bug libstdc++/119135] New: Typo in as_const range adaptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119135 Bug ID: 119135 Summary: Typo in as_const range adaptor Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug libstdc++/115218] The conversion constructor of concat_view::iterator always default-constructs variant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218 --- Comment #9 from 康桓瑋 --- (In reply to Patrick Palka from comment #8) > Fixed, thanks! The fix for LWG 4082 is the missing viewable_range constraint for one pack case.

[Bug libstdc++/119022] ranges::inplace_merge should check for iterator_concept, not iterator_category

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #2 from 康桓瑋

[Bug libstdc++/115209] The implementation of concat_view refers to p2542r7 rather than the p2542r8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 --- Comment #7 from 康桓瑋 --- (In reply to 康桓瑋 from comment #6) > (In reply to Patrick Palka from comment #5) > > (In reply to 康桓瑋 from comment #4) > > > > Our concat_view implementation is accidentally based off of an older > > > > revisi

[Bug libstdc++/115209] The implementation of concat_view refers to p2542r7 rather than the p2542r8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 --- Comment #6 from 康桓瑋 --- (In reply to Patrick Palka from comment #5) > (In reply to 康桓瑋 from comment #4) > > > Our concat_view implementation is accidentally based off of an older > > > revision of the paper, P2542R7 instead of R8. A

[Bug libstdc++/115209] The implementation of concat_view refers to p2542r7 rather than the p2542r8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 --- Comment #4 from 康桓瑋 --- > Our concat_view implementation is accidentally based off of an older > revision of the paper, P2542R7 instead of R8. As far as I can tell the > only semantic change in the final revision is the relaxed

[Bug libstdc++/115218] The conversion constructor of concat_view::iterator always default-constructs variant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218 --- Comment #2 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > Does this also mean the iterator's default ctor needs a > default_initializable<_Vs...[0]> constraint? The variant constructor already has such a constraint.

[Bug libstdc++/118156] New: flat_set::insert_range cannot handle non-common ranges

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118156 Bug ID: 118156 Summary: flat_set::insert_range cannot handle non-common ranges Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug libstdc++/118083] New: __possibly_const_range misses input_range constraint

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118083 Bug ID: 118083 Summary: __possibly_const_range misses input_range constraint Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compon

[Bug libstdc++/118022] New: : _Copy_awaiter should explicitly construct _Yielded_decvref

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118022 Bug ID: 118022 Summary: : _Copy_awaiter should explicitly construct _Yielded_decvref Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/118020] New: SIGSEGV in std::generator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118020 Bug ID: 118020 Summary: SIGSEGV in std::generator Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee

[Bug libstdc++/117998] New: : views::counted misses difference casting for contiguous_iterator case

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117998 Bug ID: 117998 Summary: : views::counted misses difference casting for contiguous_iterator case Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/117873] New: Spurious -Wmaybe-uninitialized warnings with -O3 for static const std::regex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117873 Bug ID: 117873 Summary: Spurious -Wmaybe-uninitialized warnings with -O3 for static const std::regex Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: n

[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 --- Comment #4 from 康桓瑋 --- (In reply to Patrick Palka from comment #3) > (In reply to 康桓瑋 from comment #2) > > (In reply to Patrick Palka from comment #1) > > > Interesting, I guess 'auto x = *iter;' should never be done in generic > > > code

[Bug libstdc++/117541] New: vector::insert_range should not use ranges::copy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117541 Bug ID: 117541 Summary: vector::insert_range should not use ranges::copy Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 --- Comment #2 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > Interesting, I guess 'auto x = *iter;' should never be done in generic code > then? Yap, even 'range_value_t x = *iter;'.

[Bug libstdc++/117094] New: ranges::fill misses std::move for output_iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117094 Bug ID: 117094 Summary: ranges::fill misses std::move for output_iterator Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 --- Comment #3 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #2) > (In reply to 康桓瑋 from comment #1) > > std::bitset has similar issues: > > > > #include > > > > std::bitset<1> bitset; > > typename std::bitset<1>::reference bit_ref(b

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #10 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #9) > Currently aliases_view is allowed to be a common range, but not required to > be. > > If we specify that its sentinel type is std::default_sentinel, that would > requi

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #8 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #7) > "Note that this view is not common_range because it can be implemented more > efficiently > without that requirement, and, being copyable, it can be adapted into one." >

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 --- Comment #5 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #4) > Thanks! I'll submit an LWG issue to add something saying there's an > unspecified constructor, or just say explicitly that it's not default > constructible. Not sure it

[Bug libstdc++/116399] New: C++26 text_encoding​::​aliases_view is not default-constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399 Bug ID: 116399 Summary: C++26 text_encoding​::​aliases_view is not default-constructible Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

  1   2   3   4   5   6   >