Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC accepts this invalid code:
namespace N1 {
int &f();
}
namespace N2 {
struct N1 {
floa
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
See https://bugs.llvm.org/show_bug.cgi?id=45287 for some background.
The C++ language rules do not permit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #2 from Richard Smith ---
(In reply to Marc Glisse from comment #1)
> (In reply to Richard Smith from comment #0)
> > The C++ language rules do not permit optimization (eg, deletion) of direct
> > calls to 'operator new' and 'operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #4 from Richard Smith ---
(In reply to Andrew Pinski from comment #3)
> PR 23383 is where part of the discussion was done.
>
> In fact GCC implements the optimization without the builtin:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #6 from Richard Smith ---
(In reply to Marc Glisse from comment #5)
> Ah, since you are here, and you appeared as an author of N3664 but not N3537
> (precisely when this subtlety happened), could you explain why? It isn't
> discussed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569
--- Comment #4 from Richard Smith ---
(In reply to Richard Biener from comment #3)
> But isn't the alignas(32) also "appertaining to that entity"?
No. The alignas(32) appertains to the struct. This is specified in [class]/2:
"The optional attrib
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A {
int *p;
constexpr ~A() { *p = 0; }
};
static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #16 from Richard Smith
---
Per p0593, memcpy implicitly creates objects (of any implicit lifetime type) in
the destination. It does not propagate the objects in the source memory to the
destination memory, and can therefore be used t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #18 from Richard Smith
---
(In reply to Andrew Downing from comment #17)
> Also none of the behavior described in p0593 is required for this C++
> program to be well defined. All objects that are required to exists here are
> created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #20 from Richard Smith
---
(In reply to Andrew Downing from comment #19)
> Not that it would make a difference in this particular situation, but is the
> intent of P0593R6 to only allow implicitly creating an object in the
> relevant
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A {
friend struct B *f();
};
B *p;
GCC rejects this saying that 'B' is not dec
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
int f(int (*p)[], int (*q)[3]) { return p < q; }
This is a constraint violation in C99,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #37 from Richard Smith
---
(In reply to Richard Biener from comment #36)
> The main issue I see is that this differing expectations of C and C++ are
> impossible to get correct at the same time.
That is a rather bold claim. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59978
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A { template operator T(); };
struct X {};
struct B { friend A::operator X(); };
Per [temp.mem
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
template struct A { using type = U; };
template using B = A;
template class Z> struct Q {
using t
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
typedef __typeof(9223372036854775808LL) T;
produces the warning:
:1:18: warning: integer c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #3 from Richard Smith ---
In the mean time, what is GCC's intent here? Clang is following the behavior
described by GCC's diagnostic text, treating decimal integer literals that
don't fit in 'long long' but do fit in 'unsigned long lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #4 from Richard Smith ---
(In reply to Richard Smith from comment #3)
> such a literal "has no type" in C, which presumably results in undefined
> behavior
Ah, no, C11 6.4.4/2 makes this a constraint violation. But either way I think
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC accepts this invalid code (which is ill-formed because [dcl.init.aggr]/8
says it potentially-invokes the
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
[Probably no-one will ever write code like this outside a compiler test case,
but
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
The convention for type trait builtins adopted by essentially every C++
compiler vendor is to expose std::SOME_TRAIT::value as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169
--- Comment #2 from Richard Smith ---
Still crashes GCC trunk from today:
https://godbolt.org/z/zWvT4w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169
--- Comment #4 from Richard Smith ---
Aha! godbolt.org implicitly adds -g to its command line. Try that; that causes
a crash for this testcase for me with GCC 9.2.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56528
Bug #: 56528
Summary: __attribute__((visibility)) ignored for a function
declaration with an asm label
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56582
Bug #: 56582
Summary: ICE on negative array index in C++11 constant
expression evaluation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526
--- Comment #4 from Richard Smith
2012-10-28 05:21:40 UTC ---
The fix does not appear to be correct. C++11 changed the lexing rules, not the
parsing rules for template argument lists. For instance, this is valid in
C++11:
int a;
bool b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
Richard Smith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
g++ has a rejects-valid on this:
template int f() {
T n = 0;
struct X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
If a temporary is lifetime-extended by being bound to a reference wit
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Consider:
#include
struct A {
A() { std::cout << " A()" << std::endl; }
~A() { std::cout << "~A()" &
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57942
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Given
struct S {
mutable int n;
constexpr S() : n() {}
};
GCC correctly accepts:
constexpr S s {};
but incorrectly rejects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328
Richard Smith changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986
Bug #: 50986
Summary: weak static data members with constant initializers
emitted in .rodata, leading to segfault on startup
Classification: Unclassified
Product: gcc
Version: 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578
Bug #: 53578
Summary: include/ext/concurrence.h relies on ill-formed
narrowing conversions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986
--- Comment #2 from Richard Smith
2012-02-01 21:14:35 UTC ---
As noted in comment#0, I believe there is no ODR violation here. Each
definition of U::k consists of the same sequence of tokens, every name
refers to the same entity in both definitio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130
Bug #: 52130
Summary: missing check for matching underlying type during
instantiation of enum member of class template
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119
--- Comment #8 from Richard Smith
2012-02-13 22:17:27 UTC ---
Signed left shift which overflows the corresponding unsigned type is still
undefined, so g++ should reject this:
constexpr int n = 2 << 31;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58752
--- Comment #7 from Richard Smith ---
(In reply to Daniel Krügler from comment #6)
> (In reply to Richard Smith from comment #4)
> Richard, could you please explain what precisely you meant with:
>
> "Deducing #1 from #2 gives T=const U, which re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #5 from Richard Smith ---
(In reply to Jonathan Wakely from comment #2)
> I thought if the partial specializations were ambiguous then these function
> overloads should be too.
Yes, this inconsistency is very surprising. GCC, EDG, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #8 from Richard Smith ---
(In reply to Walter Mascarenhas from comment #7)
> In itself, Richard's paragraph "Morally, the function should ambiguous... "
> implies that the code below is ambiguous. However, it
> compiles just fine with
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Consider:
void f() {}
template struct X {};
template struct Y {};
constexpr void (*p)() = &f;
X a;
const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59372
--- Comment #1 from Richard Smith ---
(In reply to Richard Smith from comment #0)
> X c;
> X d;
Sorry, transcription error, these should be 'Y', not 'X'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59426
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Reduced testcase:
struct string {} a[1];
struct pair {
string s[1]; pair() : s(a) {}
};
This is ill
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
GCC rejects this:
template struct X {
template struct Y;
template struct Y { int x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51433
Bug #: 51433
Summary: constexpr caching leads to incorrect dynamic
initialization
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51541
Bug #: 51541
Summary: ICE on ill-formed alias template declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
--- Comment #5 from Richard Smith ---
This was just reported as http://lists.isocpp.org/core/2018/12/5320.php; I
don't believe it's on the core issues list yet.
[@Tomalak, I think the standard is clear here:
"If the assignment-expression in th
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Consider:
inline int &&r = 0;
int *p = &r;
GCC mangles the lifetime-extended temporary as _ZGR1r0, which doesn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76995
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60352
--- Comment #3 from Richard Smith ---
This bug still exists in GCC trunk.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC rejects this valid code:
template T f() { using T::Bar; return Bar; }
As follows:
: In function 'T f()':
:2:39:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
--- Comment #11 from Richard Smith
---
The point of trivial (as distinguished from trivially-copyable) is that an
instance of type T can be created and "properly" initialized (albeit left with
an indeterminate value) without executing any code.
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC rejects these valid examples, producing a bogus "exp
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
#include
using T = int;
size_t e() {
std::vector vb;
return vb.max_size();
}
size_t f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266
Richard Smith changed:
What|Removed |Added
Version|unknown |8.3.0
--- Comment #3 from Richard Smith
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Imported from https://llvm.org/PR14117
template struct IsConvertible {
static const bool value =true;
};
template struct EnableIf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90792
--- Comment #3 from Richard Smith ---
(In reply to Andrew Pinski from comment #2)
> Related to the upstream ABI issue:
> https://github.com/itanium-cxx-abi/cxx-abi/issues/38
I don't think so, except that they're both about the 'sr' mangling in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86501
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67898
--- Comment #2 from Richard Smith ---
(Clang trunk now accepts both testcases.)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct X { ~X(); operator bool(); };
void f(X &);
void g() { for (; X x = X(); f(x)); }
GCC miscompiles thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
--- Comment #1 from Richard Smith ---
For easy reproduction: https://godbolt.org/g/dfZFxz
This does not appear to be a regression: this example appears to be miscompiled
by every version of GCC back to at least 4.1.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Live testcase: https://godbolt.org/g/AKn7j7
For posterity:
#include
struct A {
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849
--- Comment #1 from Richard Smith ---
Interestingly, GCC does appear to suppress guaranteed copy elision if the class
has virtual base classes.
Perhaps GCC's approach to this problem is to assume that a function returning a
T by value cannot to
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Per https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html a function
containing a computed goto can be
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Live testcase: https://godbolt.org/z/1JYWJS
For posterity:
struct A {
constexpr A
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
It's my understanding that __atomic_load is supposed to work for an essentially
arbitrary TYPE, including the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59372
Richard Smith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237
--- Comment #2 from Richard Smith ---
(In reply to Alexander Monakov from comment #1)
> GCC assumes the access is sufficiently aligned for an atomic object of
> corresponding type
I think that's only true for objects whose size corresponds to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237
--- Comment #4 from Richard Smith ---
(In reply to Alexander Monakov from comment #3)
> With GCC size/align are 3/1 while with Clang it's 4/4 as you said
Oh sorry, you're right, I'd forgotten about this ABI discrepancy. We really
need to get the
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
CC: timshen at gcc dot gnu.org
Target Milestone: ---
GCC (all versions) miscompiles this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414
--- Comment #2 from Richard Smith ---
> Where does the scope of object A inside Foo begin and end?
There is formally only one object. The object constructed in the return
statement of Foo is simply the same object that is named 'a' within Bar.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC's documentation of GNU C extensions appears not to mention allowing raw
string literals in C, which GC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53841
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
Bug #: 56158
Summary: bad enum values computed by operator~ in ios_base.h
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
See also bug 52023.
On i386, according to GCC we have _Alignof(double) == 4, but according to G++
we have alignof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69763
--- Comment #3 from Richard Smith ---
I'm pretty sure neither the C nor C++ committees intended for alignof(T) to
give different results in the different languages. And even with the rule in
[basic.align]p2, GCC can still choose to specify that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57433
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57745
--- Comment #3 from Richard Smith ---
Yes, this is now fixed; the remaining difference is a defect in the standard.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
g++ -std=c++11 -pedantic-errors has a rejects-valid on this:
template struct S { enum class E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130
--- Comment #3 from Richard Smith ---
The diagnostic in #1 is not only wrong for this case, it's also a rejects-valid
in the case where the underlying types match. I've filed
https://gcc.gnu.org/PR81895 for that.
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Example mangled name where demangler walks past two nuls:
$ echo '__thunk_16\0_\0_3foo' | c++fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80513
--- Comment #1 from Richard Smith ---
While we're here, this check for overflow in consume_count is nonsense, and any
decent optimising compiler is going to optimise away the overflow check:
https://github.com/gcc-mirror/gcc/blob/master/libibert
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct B { int n; };
struct A
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81145
--- Comment #2 from Richard Smith ---
I've tried a few things and not found any way to get wrong code. I think you're
right that this is just a diagnostic issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81145
--- Comment #5 from Richard Smith ---
Yes, according to godbolt this occurs in GCC 4.4 - 7.1, but not in trunk.
Unlike PR80593, it does not appear to be a GCC 7 regression, but it sure seems
plausible that that change fixed it =)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A {
A();
void *operator new(unsigned long, void*);
private:
void operator delete(void
1 - 100 of 196 matches
Mail list logo
