http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948
Summary: ICE with -ftree-parallelize-loops: "address taken, but
ADDRESSABLE bit not set"
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49948
--- Comment #1 from Arthur O'Dwyer
2011-08-02 17:43:00 UTC ---
Created attachment 24895
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24895
Output of "gcc-4.5 -O3 -ftree-parallelize-loops=2 -std=c99 -c test.c -v"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227
--- Comment #5 from Arthur O'Dwyer
2011-08-02 17:47:20 UTC ---
Confirmed that my testcase no longer reproduces, as of svn revision 177081 or
earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49997
Summary: ICE in inline_small_functions with
-fnon-call-exceptions
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50039
Bug #: 50039
Summary: Segfault in vect_operation_fits_smaller_type()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067
Bug #: 50067
Summary: Wrong code with -fpredictive-commoning
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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=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=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;
templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68003
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
#include
#include
struct S {
void operator delete(void*);
};
static_assert(std::is_same_v<
decltype(S::operator delete),
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/7onfa6
struct G {
static int min(int=0) { return 1; }
int min() &&am
verity: 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/841ahx
template struct A;
A<{}> a;
In -std=c++17 mode, this gives an error as expecte
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/sxWY1f
template
concept C = requires (P ptr) { (struct D*)ptr
11.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/qq7196
struct S {
template s
++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/xavfej
#include
struct Incomplete;
template struct Holder { T t; };
Holder *p;
void test() {
::new (p) int;
new (p) int;
}
In an "ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/96EEPa
struct Base {};
struct Derived : Base {};
Derived t() { Base b; return Derived(b); }
// https://godbolt.org/z/G4covG
auto lam = [i
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://
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/qh1zos
template concept Signed = bool(T(1));
static_assert(Signed);
Compile with "-std=c++20&
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/hx7h7v
struct Base {
virtual int f
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
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
: 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=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
: 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=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
: 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
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()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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
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
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=92505
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=94673
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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=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
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=87697
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: ---
// 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=108216
--- Comment #1 from Arthur O'Dwyer ---
Possibly tangentially related: #70644, #81051
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
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=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
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 #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 return
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=114479
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
-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=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<...
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=101943
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=106611
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=86646
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 #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=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=94039
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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=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
++
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=100248
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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=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
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=93106
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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=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 be
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
: 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
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)
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99524
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102470
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
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>();
-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=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
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
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
: 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
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
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 #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
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
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
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
: 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
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
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
: 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--()
101 - 200 of 221 matches
Mail list logo
