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;
>
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
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
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
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++
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
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("
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
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);
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
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
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.
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
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.
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).
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
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++
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
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++
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
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
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
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
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
>
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
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
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,
>
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,
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
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;
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
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
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.
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++
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427
--- Comment #1 from 康桓瑋 ---
flat_set has the same issue.
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
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
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
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++
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
康桓瑋 changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #2 from 康桓瑋
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
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
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
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.
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
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
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
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
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
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
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
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:
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;'.
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
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
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
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."
>
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914
--- Comment #2 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is a dup of bug 113460.
Definitely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914
Bug ID: 115914
Summary: SIGSEGV when std::generator co_yield different ranges
of elements
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846
--- Comment #8 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > (In reply to Andrew Pinski from comment #1)
> > > I think it is due to:
> > > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Stor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846
--- Comment #7 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Andrew Pinski from comment #1)
> > I think it is due to:
> > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Storage() { }
> >
> > Which was done in r12-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846
Bug ID: 115846
Summary: std::optional> is constant
expression even in C++20 mode
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
--- Comment #8 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #7)
> Fixed now, thanks for the reports.
Thanks for the quick fix. There may be another potential issue that I don't
know if it is worth mentioning.
When the difference_typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115814
Bug ID: 115814
Summary: class template argument deduction failed in C++20
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
--- Comment #3 from 康桓瑋 ---
(In reply to Tamar Christina from comment #2)
> I also get an ICE related:
>
> /opt/buildAgent/temp/buildTmp/toolchain/include/c++/15.0.0/bits/stl_algo.h:
> 3873:38: error: no match for 'operator+' (operand types are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115803
Bug ID: 115803
Summary: ICE: tree check: expected class 'type', have
'constant' (integer_cst) in cp_type_quals, at
cp/typeck.cc:11646
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
Bug ID: 115799
Summary: ranges::find's optimized branching for memchr is not
quite right
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792
--- Comment #7 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #6)
> So I looked into the change for clang:
> https://github.com/llvm/llvm-project/commit/
> 0620e6f4b76a9725dbd82454d58c5a68a7e47074
>
> And they didn't add a testcase for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792
Bug ID: 115792
Summary: GCC accepts [] throw () {}
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425
Bug ID: 115425
Summary: ICE: tree check: expected type_pack_expansion or
expr_pack_expansion, have error_mark in
tsubst_pack_expansion, at cp/pt.cc:13778
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
Bug ID: 115218
Summary: The conversion constructor of concat_view::iterator
always default-constructs variant
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115215
Bug ID: 115215
Summary: views::concat rejects non-movable references
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
Bug ID: 115209
Summary: The implementation of concat_view refers to p2542r7
rather than the p2542r8
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115145
Bug ID: 115145
Summary: Help lambda in rewritten std::variant comparisons does
not specify return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098
--- Comment #1 from 康桓瑋 ---
std::bitset has similar issues:
#include
std::bitset<1> bitset;
typename std::bitset<1>::reference bit_ref(bitset, 0); // well-formed in
libstdc++
https://godbolt.org/z/T4qvv8TcG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098
Bug ID: 115098
Summary: std::vector::iterator::reference is
default-constructible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067
Bug ID: 115067
Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
--- Comment #1 from 康桓瑋 ---
Oh, maybe this is just because MSVC does not use std::optional but uses
_Defaultabox.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
Bug ID: 115046
Summary: meta-recursion when apply join_view with as_const_view
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115045
Bug ID: 115045
Summary: views::adjacent_transform<0> is underconstrained
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000
Bug ID: 115000
Summary: Confusing 'cannot convert to 'int' in initialization'
error message
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934
Bug ID: 114934
Summary: Error message for expected unqualified-id could be
improved
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114845
Bug ID: 114845
Summary: Confusing message when using undeclared identifier of
Const
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
--- Comment #4 from 康桓瑋 ---
(In reply to Patrick Palka from comment #2)
> *** Bug 114530 has been marked as a duplicate of this bug. ***
That's my lost memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114530
Bug ID: 114530
Summary: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of
initialized
'std::__cxx11::basic_string_M_local_buf' member in constant e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #6 from 康桓瑋 ---
(In reply to Jiang An from comment #5)
> (In reply to 康桓瑋 from comment #0)
> > Since P3059R0 is closed (although I feel bad about this)
>
> BTW, now I think this is somehow unfortunate.
> P3059 behaved like a follow-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
Bug ID: 114477
Summary: The user-defined constructor of filter_view::iterator
is not fully compliant with the standard
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929
Bug ID: 113929
Summary: GCC accepts template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810
Bug ID: 113810
Summary: A lambda with this auto style that captures this in a
member function cannot use this pointer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Bug ID: 113802
Summary: gcc rejects auto f(this auto self...) { }
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Bug ID: 113788
Summary: Deducing this is broken with structured binding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113640
--- Comment #1 from 康桓瑋 ---
Noted that changing `this auto self` to `this auto&& self` will get the
expected results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113640
Bug ID: 113640
Summary: 'deducing this' lambda invoked multiple times
unexpectedly
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
--- Comment #2 from 康桓瑋 ---
more reduced:
struct Base {
operator int(this auto&&) {
return 42;
}
};
int main() {
Base b;
// return static_cast(Base{}); // ok
return static_cast(b); // error
}
https://godbolt.org/z/qGrbf4rj7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
--- Comment #1 from 康桓瑋 ---
test:
https://godbolt.org/z/jdz3ejohv
1 - 100 of 526 matches
Mail list logo
