https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119576
--- Comment #8 from Arthur O'Dwyer ---
The Linux kernel disables -Warray-bounds in GCC 9 and later (and
-Wstringop-overflow unconditionally).
https://github.com/openSUSE/kernel/blame/5be5ecdaf1e7fb1a04e6122771b432851cd2393d/init/Kconfig#L905-L92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119576
--- Comment #6 from Arthur O'Dwyer ---
Will Wray points out that GCC's own codebase disables `-Warray-bounds` in
several places, including at least these places in current master:
gcc/cp/module.cc:#pragma GCC diagnostic ignored "-Warray-bounds"
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See meta-bug #56456 for both "false negative" and "false positive" reports with
-Warray-bounds.
See bug #107677 for a user asking "What is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119497
--- Comment #7 from Arthur O'Dwyer ---
> @jwakely is correct that on OSX/Darwin the macro is named `__assert_rtn`.
...er, sorry, the *non-constexpr function called by the `assert` macro* is
named `__assert_rtn`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119497
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #10 from Arthur O'Dwyer ---
> > Would it be at least possible to make the error clearer?
> I don't think that's possible to do in the library.
Agreed. IMO this bug should be marked RESOLVED at this point, because James
Knight's pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109941
--- Comment #7 from Arthur O'Dwyer ---
I've split out the `std::expected` feature request specifically into bug
#119197.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See https://quuxplusone.github.io/blog/2024/12/08/should-expected-be-nodiscard/
and
https://www.reddit.com/r/cpp/comments/1h9u4us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102116
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Y4nKfsfM8
int main() {
std::deque v;
printf("Default-constructed capacity: %zu\n"
erity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Bug #105609 is related, i.e. it's about using std::move(*it) where ADL
iter_move(it) is required; but I
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
https://godbolt.org/z/fPjoqMrYs
template
struct CW {
using V = typename decltype(T())::type;
static voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109941
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361
--- Comment #6 from Arthur O'Dwyer ---
Thanks, that looks much less noisy! (Assuming godbolt.org has updated already.)
I now see this:
// https://godbolt.org/z/WqT6hs8ed
f3, f7, and f9 now all give -Wuninitialized at -O1 and higher (and
false-
++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/M57PhYx6x
template
struct Base {
enum class E;
};
struct X;
template<> enum class Base::E { a, b };
GCC complains:
:6:41: w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116160
--- Comment #2 from Arthur O'Dwyer ---
> I am not sure this [the first case] is valid code though.
The Standard contains an example of exactly this situation:
https://eel.is/c++draft/namespace.udecl#example-8
using A::x; // OK, hides struct
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/fG1ofMq65
namespace Blah { int b; }
int main() {
using Blah::b;
using Blah::b;
}
// https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Jason Turner recently did a video on `-Wnrvo`
https://www.youtube.com/watch?v=PTCFddZfnXc and I noticed some deficiencies in
GCC's handling of his very first example. Here's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #5 from Arthur O'Dwyer ---
> Yes, so that std::copy_n benefits from the same memmove optimization as
> std::copy.
Right, I'm not objecting to the memmove optimization, just to the current
codebase's approach of "slightly pessimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/1Yo3h3rqW
#include
#include
struct It {
explicit It();
It& operator++();
It operator++(int);
It& operator--()
D
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
This is merely a very minor glitch in an error message. But I keep noticing it
when I accidenta
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Bug #115229 is related.
// https://godbolt.org/z/os63oEEax
struct GetKey {
int& rn( int& x)
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/G7qG4vvWb (C++ version)
// https://godbolt.org/z/fT793cznT (C version)
struct A { int a; short b
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See LWG 2510, "Tag types should not be DefaultConstructible":
https://cplusplus.github.io/LWG/issue2510
WG21 seems
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 be
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+,*
NCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Jiang An raises an interesting issue over at
https://github.com/llvm/llvm-project/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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
> c
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 return
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=113853
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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 IC
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
P2266 "Simpler Implicit Move", adopted for C++23, intends that a move-eligible
`x` should be treated as an xva
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/KWv8n6zEG
struct S {
int x_;
void f() {
[this](this auto) {
return this;
};
}
};
GCC trunk complains:
:5:16
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/34Wdj1ox8
template
struct S {
S(int) {}
void operator=(int) {}
void f
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/fd3zzfrTd
auto factory(int x) {
return [x=x](this auto self
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/EGv36xzY6
template struct A;
template void foo();
int i;
int main() {
foo>();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102470
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99524
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/W9P6GrG4x
#include
int main() {
try {
throw nullptr;
} catch
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
template
concept Throwable = requires { throw T(); };
struct Incomplete;
static_assert(!Throwable);
static_assert(!Throwable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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 consta
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, _b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101943
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Bug #98712 seems related.
// https://godbolt.org/z/eKKxcovEn
struct D;
struct B {
bool operator
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 `constructible_from<...
-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/9onGvqfha
#include
#include
#include
void f(std::list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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]; }
> > , at
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 bug
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://quuxplusone.github.io/blog/2023/06/03/p1144-pmr-koans/#the-evil-allocat
: 13.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
I'm not clear on the entire behavior of -Wwrite-strings; bug 61579 seems
relevant. So there's p
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 n
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, Andrew
-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Background:
https://quuxplusone.github.io/blog/2021/03/07/copy-elision-borks-escape-analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93106
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108759
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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
> a
rds: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/ex97db8cT
template
struct B {
int f() { retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100248
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/bdT84P318
template
struct A {
static void g
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.
Rig
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://gcc.godbolt.org/z/EfdG4nzv9
#include
#include
struct B {
B(int i, short j) : i(i), j(j) {}
int i
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
C++20 permits structured bindings (decomposition declarations) to be `static`.
This means we can use them in i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #1 from Arthur O'Dwyer ---
Possibly tangentially related: #70644, #81051
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/6qMTY6bGn
#include
struct A *ga = nullptr;
struct B *gb = nullptr;
struct C *gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/T1vPGYash
template
struct Array {
template
operator Array()
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
(Originally reported by Nicholas Sielicki on the cpplang Slack)
// https://godbolt.org/z/138cPv5cn
#include
#include
std::bitset<1> a = {1};
std::bitse
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 tw
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
This might be considered "not a bug", or "duplicate of #61596", or "bug but in
a different way
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) {
> std::uninitialized
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/3efs3aY67
#include
int main() {
std::vector v;
v.insert(v.begin()); // libstdc++ ac
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
GCC seems to be unable to optimize some nested array accesses of the form
p[i/N].data[i%N] into a simple ((T*)p)[i]. The C test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96441
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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
> constr
sion: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/GWjYYnrnM
template concept Y = true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81157
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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 libs
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/9zP5dP3sE
#include
struct T {
int x;
T(int) noexcept;
~T();
};
T factory(int) noexcept
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 iterat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/b3P6Ta
#include
struct Original {};
struct C {
C(const Original&);
C(C&&) noexcept;
C& operator=(const Or
1 - 100 of 221 matches
Mail list logo
