: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
GCC trunk does not accept this well-formed program in -std=c++2a mode:
constexpr int f() {
struct {
mutable int i = 41;
} s;
auto const& cs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734
Casey Carter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 90734, which changed state.
Bug 90734 Summary: [concepts] Pre-normalization substitution into constraints
of templated function breaks subsumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380
Casey Carter changed:
What|Removed |Added
CC||cjdb.ns at gmail dot com
--- Comment #6 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
--- Comment #1 from Casey Carter ---
Created attachment 31563
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31563&action=edit
Minimal test case.
Attached minimal test case. std::atomic arr[100]; compiles correctly,
so it seems to be an
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 45191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45191&action=ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419
--- Comment #3 from Casey Carter ---
8.2 and 7.4 don't ICE: https://godbolt.org/z/VznOao. I was assuming that
r266224 (the fix for #52869) likely caused the regression, although I haven't
investigated.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this TU:
template concept bool C =
requires { T::value; };
struct S { int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419
Casey Carter changed:
What|Removed |Added
Keywords|accepts-invalid |
--- Comment #6 from Casey Carter ---
Cl
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
This sample TU:
using size_t = decltype(sizeof(int));
template T&& declval();
template
void f(T(&&)[N]) {}
using U = decltype(f(declval()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303
--- Comment #5 from Casey Carter ---
IIRC my reasoning was that [random.access.iterators] specifies the operational
semantics of `a < b` to be `b - a > 0`, which suggests but doesn't quite
require that `a < b` is valid whenever `b - a` is valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this program:
template struct S {
S(T);
};
template
auto f() -> decltype(S(42)); // error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85765
--- Comment #4 from Casey Carter ---
Narrowing the error down:
template())), decltype(*U(),0) =
0>
U g(T& t, long) { return begin(t); } // #1
prog.cc: In instantiation of 'U g(T&, long int) [with T = volatile il; U =
int*; decltype (((* U(
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this program fragment with g++ -std=c++17 -fconcepts
(https://godbolt.org/g/L1b6TS):
temp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this program fragment with "g++ -std=c++17 -fconcepts"
(https://godbolt.org/g/EXDoD3):
n
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
This test program aborts because `collector`'s base `item` isn't properly
zero-initialized:
void* operator new(decltype(sizeof(int)), void* ptr) {
return ptr;
}
s
||Casey at Carter dot net
Resolution|--- |DUPLICATE
--- Comment #2 from Casey Carter ---
(In reply to Jonathan Wakely from comment #1)
> Is this a dup of Bug 65816 comment 1?
Almost exactly: the sole difference being that 65816 comment 1 obser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
--- Comment #4 from Casey Carter ---
*** Bug 85892 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82507
--- Comment #1 from Casey Carter ---
Gentle ping: working around this bug is making it incredibly hard to prototype
the Ranges design for C++20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84140
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84140
--- Comment #2 from Casey Carter ---
*** Bug 69096 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69096
Casey Carter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 69096, which changed state.
Bug 69096 Summary: [concepts] return type deduction before checking constraint
satisfaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69096
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91259
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91259
--- Comment #7 from Casey Carter ---
Thanks, Jonathan. I can confirm that grepping for "\b(concept|requires)\b"
finds a great many uses in comments, but only the one concept definition and
one requires-clause in .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67427, which changed state.
Bug 67427 Summary: [concepts] Subsumption dependence on template parameter
ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427
What|Removed |Added
--
||Casey at Carter dot net
Resolution|--- |INVALID
--- Comment #2 from Casey Carter ---
(In reply to Andrew Sutton from comment #1)
> I believe that the ambiguity is correct under the revised semantics of
> concepts.
I agree. Happy fourth bi
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this well-formed TU (https://godbolt.org/z/8HYWSC):
template
constexpr bool is_integral_(...) {
return false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125
--- Comment #2 from Casey Carter ---
(In reply to Jonathan Wakely from comment #1)
> Is this valid in C++20?
Definitely not: there are no concept functions in C++20.
>
> I think G++ is correct to reject it due to redeclaring C1, C2 etc. as a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380
--- Comment #2 from Casey Carter ---
You can work around this bug by using a trailing requires-clause instead of
putting the requires-clause in the template-head.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89610
--- Comment #2 from Casey Carter ---
This isn't a "missed-optimization", it's non-conforming behavior. The
Allocator-aware container requirements
(http://eel.is/c++draft/container.requirements.general#16.sentence-41) require
only that the element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86044
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82171
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 46430
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46430&action=edit
Minima
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 46447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46447&action=edi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Compiling this well-formed program:
template
concept bool Concept = T::f() == 0;
struct ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 86493, which changed state.
Bug 86493 Summary: [concepts] Hard error for "call to non-'constexpr' function"
in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86493
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86493
Casey Carter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 44932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44932&action=edit
Preprocessed repro
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
||
CC||Casey at Carter dot net
--- Comment #1 from Casey Carter ---
Created attachment 37879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37879&action=edit
Minimal non-concepts (C++14) test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
Casey Carter changed:
What|Removed |Added
Attachment #36170|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
--- Comment #1 from Casey Carter ---
This bug is present in both 5.3 and 6.0; it should probably be attached to the
friend meta-bug 65608 since it is a "friend" issue.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Since C++14 requires value-initialized Forward iterators to compare equal, and
subtraction/ordering of RandomAccess iterators is based on equality, this
program should run to completion
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
This program should compile without error:
namespace N {
struct S {
friend void f(S&) {}
};
names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
--- Comment #2 from Casey Carter ---
[basic.lookup.unqual]/9 says that name *lookup* inside friend functions defined
inline works as it does in member functions, but that doesn’t necessarily imply
that the friend function should have the same *ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
--- Comment #3 from Casey Carter ---
> I'm inclined to the second interpretation, which would imply the behavior
> described in this bug report is what the standard intends.
This is me stumbling over my words attempting to say "I think this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
--- Comment #5 from Casey Carter ---
(In reply to TC from comment #4)
>
> I don't think that reading makes much sense. Among member-declarations that
> do not declare a member are static_assert-declarations and unnamed bit-field
> declarations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70522
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70522
--- Comment #5 from Casey Carter ---
(In reply to Jason Merrill from comment #4)
> (In reply to Casey Carter from comment #2)
> > This is a regression of sorts, FWIW, gcc 4.3 compiled it correctly
> > (http://melpon.org/wandbox/permlink/Efjfvay0U
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 38483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38483&action=edit
Minimal te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117
--- Comment #1 from Casey Carter ---
Very closely related, but not an exact duplicate of, PR 71105.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
This program should compile without error:
namespace foo {
namespace bar {
class foo {};
}
class baz {};
}
using namespace foo::bar;
::foo::baz mybaz;
but GCC 6 reports (http
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 38540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38540&action=edit
Repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
--- Comment #6 from Casey Carter ---
ODR-use of different specializations of the same partially-specialized variable
template still trigger the error in GCC 6 (Error: symbol `x' is already
defined):
template
bool x = false;
template
bool x =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71364
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 41321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41321&action=edit
Repro (sorry, not library-free)
gcc 7.1.1 20170504 and 8.0.0 2017050
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
GCC 4/5/6/7/8 diagnose this correct program:
namespace std {
template struct extent;
}
using namespace std;
template
struct S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80633
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #2
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
GCC 6.3/7.1/trunk as of 20170621 all diagnose this ill-formed program
(https://wandbox.org/permlink/uatmNSnlLbhvSvls
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
g++ 6.2 (not 5.4, or 4.9, or 4.8, or trunk) generates bad code for the attached
repro at -O2 and higher. "silent bad codegen" just barely trumps "already fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #2 from Casey Carter ---
Created attachment 40371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40371&action=edit
compressed preprocessed repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #5 from Casey Carter ---
I have verified that gcc-6-branch compiles the repro correctly, so yes, this is
a dup of PR78047.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r244608 with -std=c++1z fails to compile this program both with and without
-fno-new-inheriting-constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858
--- Comment #1 from Casey Carter ---
This seems to be a duplicate of PR 68812.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79143
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
||Casey at Carter dot net
Resolution|--- |FIXED
--- Comment #1 from Casey Carter ---
This no longer reproduces on 6.3 or trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67384, which changed state.
Bug 67384 Summary: [concepts] More fun with deduction constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67384
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67150, which changed state.
Bug 67150 Summary: [c++-concepts] Expression constraint fails with dependent
types used as a deduction constraint target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67150
What|
||Casey at Carter dot net
Resolution|--- |FIXED
--- Comment #1 from Casey Carter ---
This fails to reproduce on both GCC 6.3 and trunk.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 40772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40772&action=edit
Minima
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78715
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 42483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42483&action=edit
Repro
Trunk as of 20170825 miscompiles this program
(https://wandbox.org/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67595
--- Comment #5 from Casey Carter ---
The original program submission is ill-formed due to the requirement on line
270 being poorly designed:
requires std::is_same::value;
for a random access iterator x, "x - (x - x)" is typically a prvalue of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82768
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #2
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 39586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39586&action=edit
Patch
Both static_asserts in this program fail:
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
--- Comment #4 from Casey Carter ---
Any chance of applying this to 6-branch as well? This is breaking both range-v3
and cmcstl2 in a nasty and hard-to-workaround way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
--- Comment #11 from Casey Carter ---
Thanks again Ville - I owe you a beer in Issaquah.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 39934
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39934&action=edit
Minimal repro
This TU, which
||Casey at Carter dot net
Resolution|--- |FIXED
--- Comment #1 from Casey Carter ---
This no longer reproduces with 6.2 or trunk.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 35558
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35558&action=edit
testcase.cpp
Bot
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 35576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3557
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 35604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35604&action=edit
testcase.cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66184
Casey Carter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66184
--- Comment #2 from Casey Carter ---
Correction: r223462 was a fix on the c++-concepts branch, the trunk fix was
r223461.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Created attachment 31809
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31809&action=edit
Minimal test case.
Originally repo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768
--- Comment #1 from Casey Carter ---
This behavior would appear to NOT be erroneous. I was operating under the
assumption that the behavior of the std::thread constructor and std::bind were
identical by design given that both use the "INVOKE" mach
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 36323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36323&action=edit
Preprocessed te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67545
Casey Carter changed:
What|Removed |Added
Severity|normal |major
--- Comment #1 from Casey Carter -
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
While implementing the Ranges TS I've found that the implementation of concepts
in GCC scales very poorly to larger and more complex systems. I've been able to
a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r228351 fails to compile this correct program:
template
constexpr bool Test = true;
template )>
void f();
with error:
~/gcc6-r228351/bin/g++ -std=c++14 -c foo.cpp
foo.cpp:4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67810
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r223851 fails to compile this correct program fragment:
struct Ptr {
int* p;
constexpr Ptr(int* p) noexcept : p{p
1 - 100 of 152 matches
Mail list logo
