: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
class C;
auto x = [](MyC *p) {
return p->n;
};
class C {
int n;
friend decltype(x);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #9 from Richard Smith ---
I don't think we intended for default arguments of class-scope lambdas to get
the same complete-class context treatment as default argument of member
functions, but the standard wording does currently seem
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC permits __restrict-qualified member functions. When combined with
ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110938
--- Comment #4 from Richard Smith ---
Looks like the trait difference only happens if the templated constructor is
not deleted, but the ABI mismatch happens regardless. Possibly there are two
separate issues here?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase: https://godbolt.org/z/rKG8c166f
```
template struct Error {
//static_assert(false);
using type = T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
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
Target Milestone: ---
Testcase:
template struct X {};
int arr[32];
constexpr void *id(void *p) { return p; }
void f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
--- Comment #2 from Richard Smith ---
Hm, that doesn't explain why the second example I gave is accepted. But I
suppose what's happening there is probably just that the `packed` attribute is
ignored entirely for fields with alignment 1, so this
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: ---
As a workaround for people hitting #36566, I think GCC should accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #16 from Richard Smith
---
(In reply to Richard Biener from comment #15)
> I was specifically looking at C++20 7.6.2.7/10 to /14 (but maybe also
> others and of course the relevant parts of the delete expression). In
> particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #14 from Richard Smith
---
If I understand correctly, you're looking for documentation that
__builtin_operator_new(size)
has the exact same semantics and permits the same optimizations as `::new T`
for a trivially-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422
--- Comment #1 from Richard Smith ---
> This should instead be mangled as T_TL__
Sorry, that's wrong; the rule we ended up with would mangle this as T_TL0__.
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 C {
template
void f(decltype([](T, auto) { return 0; })) {}
};
void g() { C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
: 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, which I believe is valid, and other compilers accept:
template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #7 from Richard Smith ---
(In reply to Patrick Palka from comment #3)
> Hmm, but according to
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.literal the
> mangling of a negative integer literal is prefixed with "n",
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct X { ~X(); int c; };
extern int n;
X *p = new X[n];
Compiling with -faligned-new=2 gives:
:3:15: internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #8 from Richard Smith ---
(In reply to Jonathan Wakely from comment #7)
> Richard S., is there any reason to use the built-ins for the constant
> evaluation case?
No, Clang's constant evaluator treats the built-ins and calls to
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase (reduced from tcmalloc):
struct Elem {
Elem* next_ = this;
Elem* prev_ = this;
};
constinit
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Example:
struct A {
template A() {}
};
template A::A();
GCC accepts this without
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
#define M
#include "foo.h"M
#include M
This produces two warnings
warning: invalid suffix on literal; C++11 requires a space betwe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99209
--- Comment #1 from Richard Smith ---
Here's a more interesting example: https://godbolt.org/z/83c36q
#include
constexpr char f(...) { return 'g'; }
constexpr decltype(auto) f_adl(auto a) { return f(a); }
namespace A {
constexpr char
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
constexpr decltype(auto) f_adl(auto a) { return f(a); }
namespace A {
constexpr int f(auto
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC rejects:
constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);
saying:
:2:20: error: conversion of 'const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #11 from Richard Smith
---
(In reply to Jonathan Wakely from comment #10)
> It looks like Clang has a bug with the inaccessible constructor too, and
> strangely inconsistent handling of the inaccessible destructor.
Access checks
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
There's no good way in ISO C or C++ to express what the GNU ,##__VA_ARGS__
extension does prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98804
--- Comment #1 from Richard Smith ---
Somewhat more reduced:
struct X { constexpr X(int&) {} };
template struct Y {};
int a;
auto h(int b) -> Y; // #1
auto h(int b) -> Y; // #2
GCC accepts #1, but for #2 it produces seven (!) error messages:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
--- Comment #6 from Richard Smith ---
My apologies, I misread the testcase. Yes, this is UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
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: ---
GCC accepts this invalid code (which is ill-formed because [dcl.init.aggr]/8
says it potentially-invokes
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
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
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: intege
: 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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
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=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
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
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 declared, which
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
>
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
>
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
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=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
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=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=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/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
: 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
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 ();
}
namespace N2 {
struct N1 {
float
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.
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
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
: 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
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=67898
--- Comment #2 from Richard Smith ---
(Clang trunk now accepts both testcases.)
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=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
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=90266
Richard Smith changed:
What|Removed |Added
Version|unknown |8.3.0
--- Comment #3 from Richard Smith
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
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
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.
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: error: 'T
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Consider:
inline int & = 0;
int *p =
GCC mangles the lifetime-extended temporary as _ZGR1r0, which doesn't match the
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
: 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 GCC has
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59372
Richard Smith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 where
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
: 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
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
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
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.
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 miscomp
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=76995
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
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.
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60352
--- Comment #3 from Richard Smith ---
This bug still exists in GCC trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59930
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81347
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78724
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65157
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
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.
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=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=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.
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=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:
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++filt
virtual
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Consider the following:
template<template typename> struct A;
template typename> struct B;
1 - 100 of 189 matches
Mail list logo
