https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
--- Comment #3 from Arthur O'Dwyer ---
Re comment 2: My original test code was "invalid-code", but here's one I
believe to be "valid-code" in C++20.
// https://godbolt.org/z/dqcWeq
template class A>
struct G {
template using B = A;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68003
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98639
Bug ID: 98639
Summary: GCC accepts cast from Base to Derived in C++20 mode
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98039
Bug ID: 98039
Summary: Member function template with dependent return type
involving class's own name: wrong-mangling,
accepts-invalid
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97988
Bug ID: 97988
Summary: [C++20] Forward-declared class type declared inside
requires-expression gives weird inconsistencies
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249
Bug ID: 98249
Summary: Improper ADL on the `arg` in `new (arg) T`
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97801
Bug ID: 97801
Summary: overload resolution ambiguity isn't detected when
rvalue ref qualifier is involved
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97883
Bug ID: 97883
Summary: [C++20] Segmentation fault on template with
braced initializer list A<{}>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97716
Bug ID: 97716
Summary: Class's `operator delete`should be implicitly
`noexcept`
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644
Bug ID: 98644
Summary: [concepts] ICE in satisfaction_value, at
cp/constraint.cc:2825
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98639
--- Comment #5 from Arthur O'Dwyer ---
Meh, I guess this is just an unintended (but conforming) consequence of the
shifting C++17/20 rules. Jonathan links to
https://twitter.com/wakomeup/status/1274778577087627267 as another example:
//
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101353
Bug ID: 101353
Summary: [x86-64] missed optimization: missed tail call in
placement-new
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #13 from Arthur O'Dwyer ---
> And are you recommending that everyone who defines their custom contiguous
> iterators specializes pointer_traits for them? Call it _quite_ annoying...
Definitely not! When you define a contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99417
Bug ID: 99417
Summary: [C++17] std::variant assignment fails to compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99093
Bug ID: 99093
Summary: [missed optimization] Missed devirtualization
involving internal-linkage class type (but only
sometimes)
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81078
--- Comment #3 from Arthur O'Dwyer ---
Yes, this is a libstdc++ issue.
I'm not 100% sure that "the RTTI [generated by GCC] is correct," because I
don't know how to use GCC with libc++; but yeah, there's definitely at least
some problem with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
--- Comment #4 from Arthur O'Dwyer ---
> IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the
> concept-id X, they appear to be substituting {int} into X's
> constraint-expression instead of into the normal form of X's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
Bug ID: 102419
Summary: [concepts] [regression] return-type-requirement of
"Y" does not check that T::type
actually exists
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81157
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96441
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104559
Bug ID: 104559
Summary: vector v; v.insert(v.begin()); compiles, but it
shouldn't
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104792
Bug ID: 104792
Summary: [g++ and/or libstdc++] Wunused-local-typedefs + C++20
concepts = annoying
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104792
--- Comment #2 from Arthur O'Dwyer ---
@Andrew Pinski: Sorry, looks like my description ended up not matching the
Godbolt (I said "three lines marked X," but there are only two lines marked X,
for example.)
Here's the Godbolt with one of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
--- Comment #12 from Arthur O'Dwyer ---
jwakely wrote:
> Correction: they need to be the same type. We can't memcpy here:
>
> struct A { };
> struct B { B() = default; B(A) { do_stuff(); } };
>
> void (A* f, A* l, B* out) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104195
Bug ID: 104195
Summary: Fails to optimize nested array indexing
p[i/N].data[i%N]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105241
Bug ID: 105241
Summary: std::bitset::reference should have an ADL swap
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #6 from Arthur O'Dwyer ---
(In reply to James Y Knight from comment #5)
> > Does using __builtin_is_constant_p on the union member not work?
>
> I've created a proof-of-concept patch for libc++ to support SSO strings
> during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #1 from Arthur O'Dwyer ---
(Author of the blog post here.)
In contrast to James' view, I think the libstdc++/MSVC behavior is relatively
easy to explain; I think libc++'s `if consteval` approach is baroque and
confusing. [That is,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112471
Bug ID: 112471
Summary: catch handler of type "reference to array" should be
unreachable, but is reached
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106903
Bug ID: 106903
Summary: Incorrectly accepts call to function template when
deduced type doesn't match adjusted type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108257
Bug ID: 108257
Summary: Incorrect (non-unique) mangling of structured
binding's backing variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #1 from Arthur O'Dwyer ---
Possibly tangentially related: #70644, #81051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
Bug ID: 108216
Summary: Wrong offset for (already-constructed) virtual base
during construction of full object
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
Bug ID: 108846
Summary: std::copy, std::copy_n on potentially overlapping
subobjects
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109017
Bug ID: 109017
Summary: ICE on unexpanded pack from C++20
explicit-template-parameter lambda syntax
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #11 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #10)
> std::move(x,y,z) and std::copy(z,y,z) use the same underlying
> implementation, so it does have the same issue, but will be fixed by the
> same change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #23 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #22)
>
> Richi suggested that we could avoid these runtime branches (which hurt
> optimization, see PR 109445) if we knew how many bytes of tail padding there
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108759
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93106
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100248
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109381
Bug ID: 109381
Summary: Ambiguous member lookup with this-> accepted when it
should be rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
Bug ID: 110102
Summary: [13 regression] initializer_list ctors of containers
skip Allocator_traits::construct, copies move-only
type
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #4 from Arthur O'Dwyer ---
I came across the `Widget` bug in the course of writing (and it's now mentioned
in) this blog post on value semantics and PMR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #6 from Arthur O'Dwyer ---
(In reply to Jason Merrill from comment #5)
> (In reply to Arthur O'Dwyer from comment #4)
> > My first, reduced, example, where `std::list v = {1,2,3}` is accepted for
> > move-only type `A`, is 100% a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
Bug ID: 109945
Summary: Escape analysis hates copy elision: different result
with -O1 vs -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #7 from Arthur O'Dwyer ---
Richard Biener wrote:
> Are we using the wrong check or is escaping 'this'
> for these kind of classes invoking undefined behavior?
Wow, this got a lot of traffic quickly! Sounds like you (Richard,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #11 from Arthur O'Dwyer ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Arthur O'Dwyer from comment #7)
> > // https://godbolt.org/z/Ea43Y65z4
> > struct Widget {
> > int i = 1;
> ...
> > In this case, Widget has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #9 from Arthur O'Dwyer ---
(In reply to Jason Merrill from comment #8)
> (In reply to Arthur O'Dwyer from comment #6)
> > I still think it would be nice if GCC stopped supporting
> > int f(std::vector v) { return v[0]; }
> > ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110005
Bug ID: 110005
Summary: Writable strings seem too greedy in overload
resolution
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #13 from Arthur O'Dwyer ---
(In reply to Andrew Pinski from comment #12)
> I suspect this is a dup of bug 100470 then.
Yep, I agree. My previous comment was a longwinded version of jwakely's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110917
Bug ID: 110917
Summary: std::format_to(int*, ...) fails to compile because of
_S_make_span
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110917
--- Comment #2 from Arthur O'Dwyer ---
> Alternatively, we could replace the contiguous_iterator<_OutIter> constraint
> with constructible_from, _OutIter, iter_difference_t<_OutIter>>.
I think `is_same` is preferable to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101943
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110948
Bug ID: 110948
Summary: Incorrect -Winvalid-constexpr on virtual defaulted
operator==
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #6 from Arthur O'Dwyer ---
(In reply to Marek Polacek from comment #5)
> IOW, this should be accepted in C++23 but isn't (clang++ accepts in C++23):
> [...]
Correct, at least that's my intended interpretation. But the unexpected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #10 from Arthur O'Dwyer ---
FWIW, I think I agree with your analysis. To reiterate what you already said
(and I think GCC already gets the following snippet correct): in
X g (X x) try {
throw x;
} catch (...) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #30 from Arthur O'Dwyer ---
I think I understand jwakely's argument at this point, and it's consistent and
teachable. https://eel.is/c++draft/class.temporary#3.sentence-1 says:
> When an object of class type X is passed to or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #31 from Arthur O'Dwyer ---
Oops, I guess my reading did disagree with jwakely's in one small point:
jwakely writes--
> But since one of the pointers is an invalid pointer,
> you can't do anything with its value anyway, including
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Bug ID: 113789
Summary: ICE on P2266/C++23 `decltype(throw x)` where x is
move-eligible parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113427
Bug ID: 113427
Summary: ICE: tree check: C++23 `this auto` lambda + multiple
(ambiguous) inheritance from closure type
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Bug ID: 113563
Summary: Rejects capture of `this` in C++23 `this auto` lambda
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113541
Bug ID: 113541
Summary: Rejects __attribute__((section)) on explicit
instantiation declaration of ctor/dtor
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99524
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102470
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112555
Bug ID: 112555
Summary: NTTP of cv-qualified pointer type fails to mangle in
those qualifiers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
Bug ID: 112436
Summary: SFINAE-unfriendly error on throwing pointer to
incomplete type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817
Bug ID: 114817
Summary: Wrong codegen for std::copy of "trivially copyable but
not trivially assignable" type
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817
--- Comment #1 from Arthur O'Dwyer ---
Yes, vector reallocation has analogous trouble with types that are "trivial,
but not trivially copy constructible."
https://godbolt.org/z/Psboqf3MP
(libc++ happens to sidestep this pitfall *on Clang 15+,*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817
--- Comment #3 from Arthur O'Dwyer ---
https://github.com/boostorg/container/issues/153 , from 2020, is another
similar issue. There, boost::container::vector had assumed that if
__has_trivial_copy(T) and is_copy_constructible_v, then T could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Bug ID: 114898
Summary: Converting {} to a tag type should be ill-formed
SFINAE-friendly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115097
Bug ID: 115097
Summary: Strange suboptimal codegen specifically at -O2 when
copying struct type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
87 matches
Mail list logo
