https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
--- Comment #4 from Anders Granlund ---
Sounds good to me!
On Thu, 5 Aug 2021, 13:35 redi at gcc dot gnu.org,
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
>
> --- Comment #3 from Jonathan Wakely ---
> Maybe we should make this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
Anders Granlund changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The interesting thing is that if we replace struct S with struct S {}
> > both compilers agree on reject
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:
int main()
{
struct A
{
struct B *b;
};
using U = B
++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
template
class A
{
};
int main()
{
A a = A();
}
It is accepted when compiling it with "-std=c++20 -pedantic-errors".
Th
: 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:
typedef struct {
void f();
} X;
int main()
{
}
It is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97375
--- Comment #1 from Anders Granlund ---
Here is another example of the same problem without using decltype(auto), so
the problem seems to be more general:
#include
#include
template
void f1()
{
std::cout << std::is_const_v << st
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: ---
Consider the following program:
#include
: 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 program:
#include
#include
template
void f1()
{
std
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: ---
Consider the following program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96884
Anders Granlund changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=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
: 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
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
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=88731
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=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):
int main(void)
{
typedef void f(int);
typedef void f(const int
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
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
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
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: ---
GCC is behaving inconsistently for the following two test cases:
prog1.c:
static int x;
inline void g
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: ---
Consider the following two test cases (prog1.c):
void f(x)
int x;
{
}
void f(int, int);
void f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88701
--- Comment #4 from Anders Granlund ---
Thanks for the bisect.
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()
{
}
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=88695
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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=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 #1 from Anders Granlund ---
Correction:
The second standard reference should be 6.7.6.3/15 and not 6.7.3/15.
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=88674
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=88667
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 [const *]);
int main() {}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
Anders Granlund changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
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|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=88582
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 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=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 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=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
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=88581
--- Comment #3 from Anders Granlund ---
Yes. That is correct.
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
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
: 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
: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
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=88525
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=88526
--- Comment #2 from Anders Granlund ---
Thanks for the clarification.
I'll report this bug for clang instead.
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
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
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
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
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
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 programs:
struct A { static const int x = 0; };
struct B : A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
--- Comment #1 from Anders Granlund ---
I have reported the same bug in clang also:
https://llvm.org/bugs/show_bug.cgi?id=24324
Richard Smith confirmed it and added this additional test case:
And likewise:
namespace N {}
namespace N = N;
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case:
namespace P{ namespace X { static int i = 1; } }
namespace Q { namespace X = P::X; }
using namespace P;
using namespace Q;
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 (proc.cc):
int main;
Compile it with the following command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67010
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #5 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #4)
> Yes you can verify that with
>
> static_assert( std::is_same::type,
> unsigned __int128>::value, "");
>
> I suppose there should be a diagnostic with -Wpeda
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 (prog.cc):
enum {} x;
int main() {}
Compile it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #3 from Anders Granlund ---
It seems like the increment of the enumerator x triggered the use of the
following compiler extension:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
This without any error messages. That is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #2 from Anders Granlund ---
(In reply to Andrew Pinski from comment #1)
> So the enum is an unsigned type so UINTMAX_MAX +1 is 0 as it is always
> representable due to the rules of unsigned types and wrapping. Unless I
> miss-underst
: 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):
#include
#include
enum { x = std::numeric_limits::max(), y };
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
--- Comment #3 from Anders Granlund ---
(In reply to Andrew Pinski from comment #2)
> Actually wait. I think this is invalid and clang is incorrect in not
> rejecting it. Because you have a call to a non constexpr in a constexpr
> function; doe
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 (proc.cc):
void g() {}
constexpr void f() { return; g(); }
int main() {}
Compile it with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #6 from Anders Granlund ---
Now I got the reply. It seems like the wording of the standard changed with the
resolution of this c++ standard core defect:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1265
So the proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #7 from Anders Granlund ---
(In reply to Anders Granlund from comment #2)
> (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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #6 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #3)
> Problem report i.e. bugzilla bug.
Ok. Done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66935
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #5 from Anders Granlund ---
*** Bug 66935 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #4 from Anders Granlund ---
I'm pulling in this test case from my related bug report.
int x = 1;
int main() {
extern int x;
using ::x;
}
I this case the program is well-formed (the two declarations in main are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #10 from Anders Granlund ---
Here comes two more test cases moved in from my related ICE on compile bug
reports:
namespace X {
struct S;
namespace Y {
namespace Z = X;
struct Z::S {};
}
}
int main() {}
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878
Anders Granlund changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #9 from Anders Granlund ---
*** Bug 66878 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #8 from Anders Granlund ---
*** Bug 66901 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66901
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=66889
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=66888
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 135 matches
Mail list logo
