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 { typedef int type; };
struct Y { typedef int type; };
void f() {
int X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118461
--- Comment #1 from Richard Smith ---
See also PR118462 -- I'm not sure if these are duplicates or not; this one
requires the variable to be declared `const`. However, GCC does reject this
simplified testcase with a lifetime error:
constexpr in
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Even after the fix for PR96630, GCC still accepts this invalid code that
accesses a variable outside its
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Even after the fix for PR96630, GCC still accepts this invalid code that
accesses a variable outside its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105864
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #15 from Richard Smith
---
(In reply to Jonathan Wakely from comment #14)
> I assume clang doesn't have __is_arithmetic, __is_scalar and __is_void
> built-ins yet, because also defines class templates
> with those names.
Clang has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
erity: 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
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 t
: 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 t
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
tatus: 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 stru
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",
The
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 repla
: 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 f(a
: 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 '
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 are
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 t
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 the
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
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
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
: 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 C99,
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
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
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 #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
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 attrib
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/legacy-ml/gcc-patches/2
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
: 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 &f();
}
namespace N2 {
struct N1 {
floa
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 as
: 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
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 g
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:
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=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
: 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
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
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=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
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
: 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
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
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=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 miscompiles thi
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 this
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.
1 - 100 of 196 matches
Mail list logo
