Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Program (main.cpp):
template
class A
{
};
class B
{
template
friend class
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Program (main.cpp):
template
class V
{
int *a;
void f()
{
this.a = 0
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
class A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96957
--- Comment #1 from Anders Granlund ---
Also see the following stack overflow post:
https://stackoverflow.com/questions/63761866/difference-in-behaviour-between-clang-and-gcc-when-trying-to-confuse-them-by-usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96957
--- Comment #2 from Anders Granlund ---
Correction to my first comment:
"GCC is correctly compiling the program with no error messages outputed. See
the discussion in: https://bugs.llvm.org/show_bug.cgi?id=47435";
should be:
"Clang is correctl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96884
Anders Granlund changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.c):
int main()
{
struct S s = (struct S { int x; }) { .x = 1 };
}
The type of s is completed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #2 from Anders Granlund ---
To what part of the standard are you refering to?
This is what I found and it allows the given program:
C11 standard 6.7.7: https://port70.net/~nsz/c/c11/n1570.html#6.7p7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #4 from Anders Granlund ---
In general the standard seems to be a bit inprecise when it talks about types
beeing complete.
The same type may be incomplete at one point in the program, but complete at
another point. The standard shoul
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following C11 program (prog.c):
int main()
{
struct { enum { a } b; };
}
This program does NOT violate
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following C11 program (prog.c):
void f(int a[sizeof(int [*])]);
int main()
{
}
Compiling it with
gcc prog.c -std=c11 -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
--- Comment #2 from Anders Granlund ---
Thanks for the clarification.
I'll report this bug for clang instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
--- Comment #2 from Anders Granlund ---
Thanks for the explanation. That makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
int main()
{
typedef _Atomic int f();
typedef int f();
}
Compilation command
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test program (prog.c):
int a[1] = { 0 };
int main()
{
int a;
{
extern int a[];
sizeof (a);
}
}
Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #2 from Anders Granlund ---
By "merging" i suppose you mean the process described at 6.2.7.4 in the
standard:
"For an identifier with internal or external linkage declared in a scope in
which
a prior declaration of that identifier i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88581
--- Comment #3 from Anders Granlund ---
Yes. That is correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582
--- Comment #2 from Anders Granlund ---
Quote from the C17 standard (the bugfix version of C11) 6.7.6.3/5:
If, in the declaration “T D1”, D1 has the form D(parameter-type-list) or
D(identifier-list[opt]) and the type specified for ident in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #4 from Anders Granlund ---
(In reply to Andrew Pinski from comment #3)
> http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_011.html
To me it looks like the resolution of that defect report (and the current
wording of the standard) i
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
enum E { x = UINT_MAX };
int main()
{
}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88625
--- Comment #1 from Anders Granlund ---
Forgot to include the include of a header file in the test case:
#include
enum E { x = UINT_MAX };
int main()
{
}
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test program (test.c):
int main()
{
int x = { { 0 } };
}
Compilation command line:
clang prog.c -Wall -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
struct S *p;
void f(void);
int main()
{
f();
*p;
}
struct S { int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582
Anders Granlund changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #5 from Anders Gra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
Anders Granlund changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
void f(int [const *]);
int main() {}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88667
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
void f(register void);
int main()
{
}
Compilation command line:
gcc prog.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88674
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
void f()
{
}
int main()
{
void (*g)(int) = 0;
&f == g;
}
Compilation command line:
gcc pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #1 from Anders Granlund ---
Correction:
The second standard reference should be 6.7.6.3/15 and not 6.7.3/15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #3 from Anders Granlund ---
Yes, the type of f does have a prototype.
That fact is however not relevant here.
Note that I'm not making any calls to f here. I am only using f in a way
that requires its type to be compatible wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #4 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> See PR 64526 and DR 317.
(Forgot to reply instead of adding an additional comment)
Yes, the type of f does have a prototype.
That fact is however not rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
--- Comment #4 from Anders Granlund ---
(In reply to jos...@codesourcery.com from comment #1)
> 6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an
> incomplete type and does not have array type, the behavior is undefined.".
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
void f(int [(int (*)[*]) { 0 } == 0]);
int main()
{
}
Compilation command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88701
--- Comment #1 from Anders Granlund ---
Another test case that also gives internal compiler error with the same
compilation command line:
void f(int n, int [(int (*)[n]) { 0 } == 0]);
int main()
{
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88701
--- Comment #4 from Anders Granlund ---
Thanks for the bisect.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
void f(a)
int a[*];
{
}
int main()
{
}
Compilation command line:
gcc prog.c -std=c11
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following two test cases (prog1.c):
void f(x)
int x;
{
}
void f(int, int);
void f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #7 from Anders Granlund ---
(In reply to jos...@codesourcery.com from comment #6)
> This looks like a case that was missed in, or broken by, my fix for bug
> 13801, which was supposed to address such cases of entities with different
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
GCC is behaving inconsistently for the following two test cases:
prog1.c:
static int x;
inline void g
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
static void f();
int main()
{
inline void f();
}
Compilation command line
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (test.c):
int main()
{
extern inline void f();
}
void f()
{
}
Compilation command line
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
static struct S s;
int main
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
int main()
{
struct S { unsigned x:4; } s;
_Generic(s.x, unsigned: 0);
}
Compilation command line
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
int main(void)
{
typedef void f(int);
typedef void f(const int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
extern void v;
int main(void)
{
_Generic(v, default: 0);
}
Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88704
--- Comment #3 from Anders Granlund ---
(In reply to Martin Sebor from comment #2)
> Confirmed, although I'd be more inclined to invest energy into including
> -Wstrict-prototypes in -Wall or -Wextra than into diagnosing the VLA in
> K&R-style de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88731
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
int main()
{
int * const p1 = 0;
int * _Atomic p2 = 0;
int * const _Atomic p3 = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
int main()
{
struct S *p = 0;
&*p;
}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors
++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35987&action=edit
prog.cc used in the command line
With the attached file the following
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35988&action=edit
prog.cc used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #3 from Anders Granlund ---
Thanks for the comments! Now I remember the following bug report that I sent to
clang:
https://llvm.org/bugs/show_bug.cgi?id=24030
That bug has now been confirmed and fixed in clang, so yes this is the ac
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35990&action=edit
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35991&action=edit
prog.cc used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878
--- Comment #3 from Anders Granlund ---
The following bug that I also reported is related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888
: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
The following core language defect has status c++11 but is not implemented yet:
http://www.open-std.org/jtc1
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35998&action=edit
prog.cc used in the
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Created attachment 35999
--> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888
--- Comment #2 from Anders Granlund ---
This bug seems to be more general than struct definitions. It also exists for
variable declarations like this:
namespace X { extern int i; }
namespace N { using X::i; }
int N::i = 1;
int main()
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
The following program is ill-formed since the two declarations in main are
conflicting
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
The following program is well-formed. The two declarations in main are not
conflicting.
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66921
Anders Granlund changed:
What|Removed |Added
CC||anders.granlund.0 at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> I think we could combine most of your reports into one or two PRs since
> they're all related and fixing them one by one would probably not be very
> efficien
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
enum {};
int main() {}
This is ill-formed according to [dcl.dcl]/5 of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
>
> So this seems invalid to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
--- Comment #4 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
>
> So this seems invalid to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Anders Granlund changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Anders Granlund changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
The following program (prog.cc in the command line below) is well-formed:
constexpr void f
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
void f() {}
inline void f();
int main() {}
It is ill-formed by [dcl.fct.spec]/4 (http
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
const union {};
int main() {}
It is ill-formed by [dcl.type.cv] http://eel.is/c++draft/dcl.dcl#dcl.type.cv-1
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
namespace N { int i; }
using namespace N;
using ::i;
int main() {}
Compile it with the following command line:
Observe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67008
--- Comment #1 from Anders Granlund ---
Forgot the command line:
g++ prog.cc -std=c++14 -pedantic-errors
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following well-formed program:
namespace N { struct x {}; }
using namespace N;
int x;
int
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
int main() {};
It is well-formed, the extra semi colon is just an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67010
--- Comment #1 from Anders Granlund ---
Detailed explanation of how the c++ standard can be applied to the program:
By [namespace.udir]/2 during the unqualified name lookup of x in sizeof (x),
the declaration struct x {}; appears as if it was de
: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
enum E {};
enum E;
int main() {}
Compile it with the following command line:
g++ prog.cc -std=c++98 -pedantic-errors
No error messages are given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
--- Comment #2 from Anders Granlund ---
That comment seems to be incorrect. The c++ standard has never forbidden empty
declarations at global namespace. I think we should get a warning instead of an
error.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
auto i = 0, f();
int main() {}
Compile it with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67016
--- Comment #2 from Anders Granlund ---
(In reply to Andrew Pinski from comment #1)
> Looks like this changed between c++11 and c++98.
>
> Note you are quoting c++11 but compiling with c++98.
>
> Also this is a big incompatibility with c99 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
--- Comment #4 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #3)
> It might have changed between the ARM and C++98, but I haven't checked.
Is ARM a c++ standard before c++98?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> C++11 mode).
I think that is because type deduction for return types of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> EDG and Clang also accept this in C++14 mode (and like GCC, reject it in
> C++11 mode).
(In reply to Anders Granlund from comment #2)
> (In reply to Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #5 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Anders Granlund from comment #3)
> > > I think that is because type deduction for return types of functions was
> > > introduced in c++14.
>
> Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #5 from Anders Granlund ---
*** Bug 66888 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66889
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #6 from Anders Granlund ---
*** Bug 66889 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #7 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #4)
> So confirming as accepts-invalid with this testcase:
>
> class A;
>
> namespace Y {
> using ::A;
> class A { };
> }
Here are two similar test cases
1 - 100 of 135 matches
Mail list logo
