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
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
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
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 <<
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
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
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
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
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
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
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;
== g;
}
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|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582
Anders Granlund changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #5 from Anders
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)
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
--- Comment #1 from Anders Granlund anders.granlund.0 at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
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 anders.granlund.0 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #5 from Anders Granlund anders.granlund.0 at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
Yes you can verify that with
static_assert( std::is_samestd::underlying_typedecltype(x)::type,
unsigned __int128::value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com ---
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
: 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 cstdint
#include limits
enum { x = std::numeric_limitsstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
--- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #6 from Anders Granlund anders.granlund.0 at gmail dot com ---
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
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
: 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 anders.granlund.0 at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
--- Comment #4 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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 #3 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67016
--- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66888
Anders Granlund anders.granlund.0 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #5 from Anders Granlund anders.granlund.0 at gmail dot com ---
*** Bug 66888 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #8 from Anders Granlund anders.granlund.0 at gmail dot com ---
*** Bug 66901 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66901
Anders Granlund anders.granlund.0 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #4 from Anders Granlund anders.granlund.0 at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66935
Anders Granlund anders.granlund.0 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #5 from Anders Granlund anders.granlund.0 at gmail dot com ---
*** Bug 66935 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #10 from Anders Granlund anders.granlund.0 at gmail dot com ---
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
1 - 100 of 135 matches
Mail list logo
