[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 --- Comment #7 from Nathan Ridge --- Based on some searching around for other users running into this error, this seems to be caused by an ld bug which was fixed in 2.32: https://sourceware.org/bugzilla/show_bug.cgi?id=24458
[Bug sanitizer/109698] gcc/g++ build/link fails for libhwasan.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com --- Comment #6 from Nathan Ridge --- I'm experiencing the same issue. I'm also on Debian 10 and using ld 2.31.1.
[Bug c++/109382] New: Error inside virtual function of class template does not show point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109382
Bug ID: 109382
Summary: Error inside virtual function of class template does
not show point of instantiation
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
Target Milestone: ---
Given the following invalid code:
struct Base {
virtual void f() = 0;
};
template
struct C : Base {
void f() override {
T().waldo();
}
};
int main() {
C obj;
}
The error is printed as follows:
$ g++-12 -c test.cpp
test.cpp: In instantiation of ‘void C::f() [with T = int]’:
test.cpp:6:8: required from here
test.cpp:7:9: error: request for member ‘waldo’ in ‘0’, which is of non-class
type ‘int’
7 | T().waldo();
| ^
The error is missing a "required from here" line pointing to `C obj;`.
If you imagine everything above main() being library code, it can be hard for a
user to tell which line of the user's code is triggering the error in the
library.
[Bug libstdc++/102807] New: Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807
Bug ID: 102807
Summary: Simple code using ranges::views::keys does not compile
with clang
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
Target Milestone: ---
Created attachment 51620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51620&action=edit
Output of `clang++ -c -std=c++20 -ftemplate-backtrace-limit=0 `
The following simple code using ranges::views::keys compiles with gcc 11.1, but
not with clang (tested with clang trunk, and libstdc++ from 11.1).
#include
#include
int main()
{
std::unordered_map m;
m | std::ranges::views::keys;
}
I've attached the complete error output. I'm not sure if this is a bug in clang
or libstdc++, but I thought I'd start here.
[Bug c++/91335] False positive "unused variable" warning with variable initialized in 'if' condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91335
--- Comment #2 from Nathan Ridge ---
I suppose a fair question here is, if I'm not going to use 'f', why don't I
just write:
if (foo()) {
return 1;
}
?
That would certainly work in this case. However, in the original code example
that motivated this report, foo() returned a class type which had a templated
conversion operator, and it's the result of that conversion operator
(instantiated with a pointer type) that I wanted to test. In such a case, I
need the declaration form to trigger invoking the conversion operator.
[Bug c++/91335] False positive "unused variable" warning with variable initialized in 'if' condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91335 --- Comment #1 from Nathan Ridge --- (In reply to Nathan Ridge from comment #0) > As a result, the only way to fix the warning is to lift the variable into > the outer scope, which can be undesirable from a code style point of view: (Well, or I could add a "(void) f;" statement in the if body. Equally undesirable.)
[Bug c++/91335] New: False positive "unused variable" warning with variable initialized in 'if' condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91335
Bug ID: 91335
Summary: False positive "unused variable" warning with variable
initialized in 'if' condition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
Target Milestone: ---
In the following code:
int* foo();
int main() {
if (int* f = foo()) {
return 1;
}
return 0;
}
GCC (tested version 9.1.0) issues the following warning with -Wall:
test.cpp: In function ‘int main()’:
test.cpp:4:12: warning: unused variable ‘f’ [-Wunused-variable]
4 | if (int* f = foo()) {
|^
I consider this a false positive because testing the variable's value in the
if-condition constitutes a use.
The language does not syntactically permit omitting the variable name here:
int main() {
if (int* = foo()) { // error: expected unqualified-id before '=' token
return 1;
}
return 0;
}
As a result, the only way to fix the warning is to lift the variable into the
outer scope, which can be undesirable from a code style point of view:
int* foo();
int main() {
int* f = foo();
if (f) {
return 1;
}
// variable 'f' still in scope here, when I don't want it to be
return 0;
}
[Bug c++/50169] [DR 2141] "new struct X {{}};" incorrectly treated as an invalid struct-definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
--- Comment #8 from Nathan Ridge ---
(In reply to Eric Gallager from comment #7)
> (In reply to Nathan Ridge from comment #6)
> > Here is another test case that MSVC accepts but GCC rejects:
> >
> > struct A {};
> > struct A* b = (1 == 1) ? new struct A : new struct A;
>
> Is this really the same thing though?
I believe it's code that was made valid by DR2141, yes. I elaborate on my
reasoning in the corresponding clang bug:
https://bugs.llvm.org/show_bug.cgi?id=34993
[Bug c++/50169] [DR 2141] "new struct X {{}};" incorrectly treated as an invalid struct-definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
Nathan Ridge changed:
What|Removed |Added
CC||zeratul976 at hotmail dot com
--- Comment #6 from Nathan Ridge ---
Here is another test case that MSVC accepts but GCC rejects:
struct A {};
struct A* b = (1 == 1) ? new struct A : new struct A;
[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 --- Comment #4 from Nathan Ridge --- (In reply to Nathan Ridge from comment #3) > This appears to have been fixed in gcc 6. Perhaps by bug 70522?
[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012 --- Comment #3 from Nathan Ridge --- (In reply to Nathan Ridge from comment #2) > This appears to be fixed in gcc 6, possibly by the same change that fixed > bug 60860 as well. Perhaps by bug 70522?
[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com --- Comment #2 from Nathan Ridge --- This appears to be fixed in gcc 6, possibly by the same change that fixed bug 60860 as well.
[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com --- Comment #3 from Nathan Ridge --- This appears to have been fixed in gcc 6.
[Bug c++/78280] GCC incorrectly accepts assignment in bitfield width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78280 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com --- Comment #1 from Nathan Ridge --- (To clarify, the reason this is incorrect is that in the C++ grammar, the bitfield width is a constant-expression, which excludes assignment-expressions.)
[Bug driver/71429] Rename -W[no-]#pragma-messages to -W[no-]pragma-messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71429 --- Comment #2 from Nathan Ridge --- Hmm, you're right. I was actually using clang, without realizing it. Sorry for the noise.
[Bug driver/71429] New: Rename -W[no-]#pragma-messages to -W[no-]pragma-messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71429 Bug ID: 71429 Summary: Rename -W[no-]#pragma-messages to -W[no-]pragma-messages Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: zeratul976 at hotmail dot com Target Milestone: --- # is a special character that begins a comment in many scripting environments, including makefiles. Escaping it is more trouble than it's worth. Please stick to boring characters in flag names.
[Bug c++/68996] New: Decltype-specifier in declarator-id should not be accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68996
Bug ID: 68996
Summary: Decltype-specifier in declarator-id should not be
accepted
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
Target Milestone: ---
GCC accepts the following code:
struct{
void test();
} a;
void decltype(a)::test(){}
I believe this is invalid, due to the following sentence in [dcl.meaning] p1:
The nested-name-specifier of a qualified declarator-id shall
not begin with a decltype-specifier.
Is this an oversight, or deliberately supported as an extension?
[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
--- Comment #1 from Nathan Ridge ---
By comparison, clang's error is:
test.cpp:1:14: error: unknown type name 'uint32_t'
enum Waldo : uint32_t {
^
[Bug c++/64758] New: [C++11] Give better error message when name of enum's base type cannot be resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
Bug ID: 64758
Summary: [C++11] Give better error message when name of enum's
base type cannot be resolved
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
For the following invalid code:
enum Waldo : uint32_t { // oops, forgot to include
A, B
};
GCC's error message is:
test.cpp:1:6: error: use of enum ‘Waldo’ without previous declaration
enum Waldo : uint32_t {
^
test.cpp:1:12: error: expected unqualified-id before ‘:’ token
enum Waldo : uint32_t {
^
This error doesn't really match the problem. A much better error would be:
test.cpp:1:6: error: use of ‘uint32_t’ without previous declaration
enum Waldo : uint32_t {
^
[Bug c++/62244] New: Function parameter should be in scope in its own default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62244 Bug ID: 62244 Summary: Function parameter should be in scope in its own default argument Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zeratul976 at hotmail dot com Consider the following code: int a; void f(int a = a); GCC accepts this code, and name lookup for the 'a' in the default argument finds the global variable 'a' (as suggested by the fact that if the global variable 'a' is commented out, GCC now gives "error: 'a' was not declared in this scope"). I believe this in incorrect. During name lookup for the 'a' in the default argument, the parameter 'a' should already be in scope, since [basic.scope.pdecl]/p1 says that "The point of declaration for a name is immediately after its complete declarator and before its initializer (if any)". Once name lookup finds the parameter, the program should then be ill-formed, because [dcl.fct.default]/p9 says "parameters of a function shall not be used in a default argument". Note that GCC has the correct behaviour when a later parameter's default argument references an earlier parameter: int a; void f(int a, int b = a); // error: local variable 'a' may not appear in this context The incorrect behaviour only occurs when a parameter's own default argument references the parameter. Note that clang rejects the first example with "error: default argument references parameter 'a'".
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 --- Comment #32 from Nathan Ridge --- (In reply to Jonathan Wakely from comment #31) > Or to put it another way, this bug only affects MinGW users, is blocked by a > limitation in MinGW, and noone from MinGW has offered to do anything about > it, but you're pointing fingers at GCC devs and saying there's a GCC clique? > Who is preventing MinGW devs joining this clique? No one, but they need to know about issues like this in order to do something about them. Above you said that this was "not possible" to fix for mingw. If you really meant "this would require changes in the mingw runtime", perhaps you should have said that. Then, even if you are not motivated to approach the MinGW developers to effect such changes, someone else (e.g. me) could have.
[Bug c++/58661] New: Definition of inherited nested class should be invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58661
Bug ID: 58661
Summary: Definition of inherited nested class should be invalid
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeratul976 at hotmail dot com
GCC accepts the following code without any errors:
struct A
{
struct nested;
};
struct B : public A {};
struct B::nested {};
I believe that this code is invalid according to [class] p11:
"If a class-head-name contains a nested-name-specifier, the class-specifier
shall refer to a class that was previously declared directly in the class or
namespace to which the nested-name-specifier refers, or in an element of the
inline namespace set (7.3.1) of that namespace (i.e., not merely inherited or
introduced by a using-declaration)"
Note that clang rejects the above code, with the error:
test.cpp:8:11: error: no struct named 'nested' in 'B'
struct B::nested {};
~~~^
[Bug c++/54864] Decltype in nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54864 --- Comment #3 from Nathan Ridge --- Since gcc and clang can't both be right, I filed http://llvm.org/bugs/show_bug.cgi?id=16828 .
[Bug c++/54310] Order of operations during overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310 --- Comment #1 from Nathan Ridge --- Richard Smith has suggested that GCC is actually allowed not to instantiate 'meta' as per [temp.inst]/p6: "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." If this is really what's happening - GCC is not instantiating 'meta' because it can determine without doing so that the first overload of 'foo' will not be chosen - then I guess we can close this PR as INVALID.
[Bug c++/53184] Unnecessary anonymous namespace warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #6 from Nathan Ridge ---
(In reply to Jason Merrill from comment #4)
> (In reply to comment #3)
> > Because then the anonymous class has the name "Foo" for linkage purposes,
> > and
> > has external linkage. When Foo referes to the const or volatile qualified
> > form
> > of the class, the anonymous class itself has no name and so no linkage, only
> > the cv-qualified form has a name for linkage purposes.
> >
> > I'm not sure if that behaviour is correct though, let's ask Jason
>
> Yes, that's right. 7.1.3:
>
> If the typedef declaration defines an unnamed class (or enum), the first
> typedef-name declared by the declaration to be that class type (or enum
> type) is used to denote the class type (or enum type) for linkage purposes
> only (3.5).
>
> typedef struct { } *ps, S; // S is the class name for linkage purposes
>
> Adding volatile means that Foo doesn't name the class, it names the volatile
> variant of the class, so it isn't the class's name for linkage purposes, so
> the class has no linkage. The warning complains about using a type with no
> linkage as a member type in a header file, since including that header in
> multiple source files would be an ODR violation as the type Foo is different
> in each translation unit.
Is this ODR violation an actual problem in practice, with GCC? I find these
warnings annoying to work around, and I wouldn't mind seeing an option to
silence them if they don't indicate an actual problem.
[Bug c++/53846] [c++11] memory exhaustion on simple recursive function template that uses decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846 --- Comment #3 from Nathan Ridge 2013-05-02 21:12:27 UTC --- This seems to be fixed in the 4.8.0 release. Close?
[Bug c++/54318] [C++11] Bogus "template instantiation depth exceeds maximum" error + segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54318 Nathan Ridge changed: What|Removed |Added Version|4.8.0 |4.7.3 --- Comment #1 from Nathan Ridge 2013-05-02 20:54:17 UTC --- This seems to be fixed in the 4.8.0 release. Should I keep the bug open so it might be fixed in the 4.7 series?
[Bug c++/51577] dependent name lookup finds operator in global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #2 from Nathan Ridge 2013-04-13 00:44:58 UTC --- *** Bug 56943 has been marked as a duplicate of this bug. ***
[Bug c++/56943] Incorrect two-phase name lookup for operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56943 Nathan Ridge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Nathan Ridge 2013-04-13 00:44:58 UTC --- (In reply to comment #1) > Please double check this isn't a Dup of PR51577 Looks that way. Closing. *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/56943] New: Incorrect two-phase name lookup for operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56943
Bug #: 56943
Summary: Incorrect two-phase name lookup for operators
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
When the following code is run:
#include
namespace N
{
struct A
{
int operator+(const void*)
{
return 42;
}
};
}
namespace M
{
struct B
{
};
}
template
int add(T t, U u)
{
return t + u;
}
int operator+(N::A, M::B*)
{
return 5;
}
int main(int argc, char** argv)
{
N::A a;
M::B b;
std::cout << add(a, &b) << "\n";
}
the output is "5". I believe the correct output wouldbe "42", because when
looking up operator+ in the expression "t + u", the operator+(N::A, M::B*)
overload is found neither by unqualified lookup at the point of definition
(since it is not declared yet at the point of definition), nor by
argument-dependent lookup at the point of instantiation (since it is not in the
namespace of either of its arguments).
Clang outputs "42" for this example, as expected.
[Bug c++/56915] [4.9 regression] ICE in symtab_add_to_same_comdat_group, at symtab.c:383
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56915 --- Comment #2 from Nathan Ridge 2013-04-12 07:40:46 UTC --- (In reply to comment #1) > I am not an expert of C++11, but I am trying to help you with this ICE. Before > I jump into the compiler to find the bugs, I guess you probably made several > mistakes in your given code. I know the code is invalid. However, an ICE is always a compiler bug, even if it's for invalid code. The compiler should give proper errors for invalid code. (In this case it gives the ICE after giving the proper errors - that's still a bug). Also, an ICE on invalid code can indicate a logic error in the compiler's code that may also be causing (yet to be discovered) ICEs on valid code. Also, just FYI: > 3)C++11 seems to only support monomorphic lambdas, if you want to use > polymorphic lambdas, you probably should use other libraries like Boost. Using a lambda inside a template does not make it polymorphic. Each instantiation of the template will have a different, monomorphic, lambda.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Nathan Ridge changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #17 from Nathan Ridge 2013-04-12 07:23:07 UTC --- (Sorry, meant to reopen with last comment.)
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
--- Comment #16 from Nathan Ridge 2013-04-12
07:22:20 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > Here is a related example that still fails to compile:
>
> Fixed.
It still fails if we make S a template:
template struct A;
template struct B : A {};
template
B operator-(F);
template
struct S
{
struct F
{
typedef S type;
};
auto foo() -> decltype(-F());
};
int main()
{
S s;
}
test.cpp: In instantiation of 'struct B >':
test.cpp:16:28: required from 'struct S'
test.cpp:21:12: required from here
test.cpp:3:42: error: invalid application of 'sizeof' to incomplete type
'S'
template struct B : A {};
^
Tested with r197837.
[Bug c++/56915] New: [4.9 regression] ICE in symtab_add_to_same_comdat_group, at symtab.c:383
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56915
Bug #: 56915
Summary: [4.9 regression] ICE in
symtab_add_to_same_comdat_group, at symtab.c:383
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
template
class A
{
typename T::type b();
};
template
void waldo(T, U);
template
void bar()
{
waldo([](A a){ return a; },
[]{});
}
int main()
{
bar();
}
GCC 4.9 (r197687) gives the following output:
test.cpp: In instantiation of 'class A':
test.cpp:13:20: required from 'bar() [with T = int]::__lambda0'
test.cpp:13:12: required from 'struct bar() [with T = int]::__lambda0'
test.cpp:14:15: required from 'void bar() [with T = int]'
test.cpp:19:14: required from here
test.cpp:4:22: error: 'int' is not a class, struct, or union type
typename T::type b();
^
test.cpp: In instantiation of 'struct bar() [with T = int]::__lambda1':
test.cpp:14:15: required from 'void bar() [with T = int]'
test.cpp:19:14: required from here
test.cpp:14:12: internal compiler error: in symtab_add_to_same_comdat_group, at
symtab.c:383
[]{});
^
0x7ae403 symtab_add_to_same_comdat_group(symtab_node_def*, symtab_node_def*)
../../src/gcc/symtab.c:383
0x687031 maybe_add_lambda_conv_op(tree_node*)
../../src/gcc/cp/semantics.c:9767
0x5a20e8 instantiate_class_template_1
../../src/gcc/cp/pt.c:9028
0x5a20e8 instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:9081
0x62b02b complete_type(tree_node*)
../../src/gcc/cp/typeck.c:131
0x56325c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:14532
0x5640a3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:13955
0x56bfaf tsubst_expr
../../src/gcc/cp/pt.c:13376
0x56c50f tsubst_expr
../../src/gcc/cp/pt.c:12855
0x56ba4b tsubst_expr
../../src/gcc/cp/pt.c:12841
0x56c824 tsubst_expr
../../src/gcc/cp/pt.c:13031
0x56a3fb instantiate_decl(tree_node*, int, bool)
../../src/gcc/cp/pt.c:18904
0x5a5946 instantiate_pending_templates(int)
../../src/gcc/cp/pt.c:19003
0x5e073d cp_write_global_declarations()
../../src/gcc/cp/decl2.c:4031
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Nathan Ridge changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #14 from Nathan Ridge 2013-04-10
09:27:10 UTC ---
Here is a related example that still fails to compile:
template struct A;
template struct B : A {};
template
B operator-(T);
struct S
{
struct F
{
typedef S type;
};
auto foo() -> decltype(-F());
};
This is compiled successfully by clang, but GCC (4.9, r197663) gives the
following error:
test.cpp: In instantiation of 'struct B':
test.cpp:15:31: required from here
test.cpp:3:42: error: invalid application of 'sizeof' to incomplete type 'S'
template struct B : A {};
^
If the operator- is replaced by a non-operator function, GCC compiles the
example successfully, which leads me to believe it's a bug.
[Bug c++/56901] [4.9 regression] lambda with implicit capture by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56901 --- Comment #1 from Nathan Ridge 2013-04-10 08:30:23 UTC --- Tested with r197663.
[Bug c++/56901] New: [4.9 regression] lambda with implicit capture by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56901
Bug #: 56901
Summary: [4.9 regression] lambda with implicit capture by
reference
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code compiles with gcc 4.8 and clang, but not with gcc 4.9:
template
void foo_impl()
{
int data;
auto L = [&](){ return data; };
[&](){ L(); }();
}
void foo()
{
foo_impl();
}
The error is:
test.cpp: In instantiation of 'foo_impl() [with =
int]::__lambda1':
test.cpp:6:12: required from 'struct foo_impl() [with
= int]::__lambda1'
test.cpp:6:19: required from 'void foo_impl() [with
= int]'
test.cpp:11:19: required from here
test.cpp:5:14: error: uninitialized const member 'foo_impl() [with
= int]::__lambda0::__data'
auto L = [&](){ return data; };
^
The error goes away if:
- foo_impl is made a nontemplate
- the call to the second lambda is inlined
- either lambda is made to capture by value instead of reference
[Bug c++/56886] New: [4.9 regression] undesirable instantiation of class template default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56886
Bug #: 56886
Summary: [4.9 regression] undesirable instantiation of class
template default argument
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code compiles with GCC 4.8 and earlier:
template
struct A
{
typedef typename T::type type;
};
template ()>
struct C;
template
struct C
{
};
C c;
but fails to compile with GCC 4.9 (2013-04-07 snapshot) with the following
error:
test.cpp: In instantiation of 'struct A':
test.cpp:16:8: required from here
test.cpp:4:30: error: 'int' is not a class, struct, or union type
typedef typename T::type type;
^
It seems that GCC 4.9 is instantiating A, the return type of the function
type A() which is the default argument for C's template parameter U, while
GCC 4.8 and earlier was not instantiating this class.
The error also has something to do with the presence of the partial
specialization of C, because removing it (and giving the primary template a
definition instead) makes it go away.
[Bug c++/56480] Explicit specialization in a namespace enclosing the specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480 --- Comment #2 from Nathan Ridge 2013-03-05 04:30:26 UTC --- (In reply to comment #1) > I think this is > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#374 Ah, I see. The code is accepted if a declaration (without definition) of the specialization is placed in the namespace. Didn't realize that.
[Bug c++/56480] New: Explicit specialization in a namespace enclosing the specialized template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480
Bug #: 56480
Summary: Explicit specialization in a namespace enclosing the
specialized template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code:
namespace Foo
{
template
struct Meow
{
};
}
template <>
struct Foo::Meow
{
};
fails to compile with gcc 4.8 (tested with 20130224 snapshot).
I believe this code should be accepted in C++11 mode as per [temp.expl.spec]
p2: "An explicit specialization shall be declared in a namespace enclosing the
specialized template." This is a relaxation of the C++03 wording: "An explicit
specialization shall be declared in the namespace of which the template is a
member".
Recent versions of clang and MSVC compile the above code in C++11 mode.
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 --- Comment #21 from Nathan Ridge 2013-01-06 02:07:40 UTC --- (In reply to comment #20) > (In reply to comment #19) > > Why not apply to gcc-4_7-branch? > > A user who can build 4.7.2 successfully should not have to update their OS to > build 4.7.3 Huh? What requires updating your OS?
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958
--- Comment #8 from Nathan Ridge 2012-11-19
03:49:39 UTC ---
(In reply to comment #6)
> No. The resolution of 1395 will not make the testcase in #1 valid, only the
> case where you have a degenerate overload, like
>
> template
> int& f(const T&, Args...);
>
> template
> int& f(const T&);
>
> The testcase in #1 should still be rejected as ambiguous.
The note describing the resolution of 1395 says "preferring an omitted
parameter over a parameter pack".
The way I read that, in the testcase in comment 1, the second overload has an
"omitted parameter" ('d'), and the first overload has a "parameter pack", so
the secodn overload would be preferred.
Am I misreading it?
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #4 from Nathan Ridge 2012-11-18 22:28:59 UTC --- I filed the same bug for clang, and I was pointed to DR1395 [1]. GCC and clang's behaviour are both in line with the resolution of this DR. I guess this can be closed as invalid then? [1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395
[Bug c++/55373] New: Partial ordering of variadic function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55373
Bug #: 55373
Summary: Partial ordering of variadic function template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
According to the last example in temp.func.order (14.5.6.2), the call to f
below should be ambiguous, but GCC compiles the code and the calls #2:
template void f(T, U...);// #1
template void f(T); // #2
void h(int i)
{
f(&i); // should be ambiguous, but calls #2
}
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
--- Comment #3 from Nathan Ridge 2012-11-07
04:32:06 UTC ---
(In reply to comment #2)
> Clang deemed this issue important enough to warrant a new entry ("Incomplete
> retrn types", under "Declared type of an expression") in their C++11 status
> page.
Link: http://clang.llvm.org/cxx_status.html
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
--- Comment #2 from Nathan Ridge 2012-11-07
04:31:24 UTC ---
Clang deemed this issue important enough to warrant a new entry ("Incomplete
retrn types", under "Declared type of an expression") in their C++11 status
page.
[Bug c++/54864] New: Decltype in nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54864
Bug #: 54864
Summary: Decltype in nested class
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code:
struct S
{
int foo();
struct nested
{
S* outer;
auto bar() -> decltype(outer->foo());
};
};
fails to compile with the following errors:
test.cpp:9:37: error: invalid use of incomplete type 'struct S'
auto bar() -> decltype(outer->foo());
^
test.cpp:1:8: error: forward declaration of 'struct S'
struct S
^
test.cpp:9:37: error: invalid use of incomplete type 'struct S'
auto bar() -> decltype(outer->foo());
^
test.cpp:1:8: error: forward declaration of 'struct S'
struct S
^
I believe this code is valid. It is accepted by clang trunk.
Tested with gcc-4.8-20121007.
[Bug c++/54377] New: Consider default arguments in "wrong number of template arguments" diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54377
Bug #: 54377
Summary: Consider default arguments in "wrong number of
template arguments" diagnostic
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following (invalid) code:
template
struct foo {};
int main()
{
foo f;
}
The error message GCC gives is:
test.cpp: In function 'int main()':
test.cpp:6:12: error: wrong number of template arguments (1, should be 4)
foo f;
^
test.cpp:2:8: error: provided for 'template struct
foo'
struct foo {};
^
I think the "1, should be 4" part is misleading, since 2 or 3 template
arguments would also be valid.
I think the error message should be changed to:
test.cpp: In function 'int main()':
test.cpp:6:12: error: wrong number of template arguments (1, should be 2 to 4)
foo f;
^
test.cpp:2:8: error: provided for 'template struct
foo'
struct foo {};
^
[Bug c++/54318] New: [C++11] Bogus "template instantiation depth exceeds maximum" error + segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54318
Bug #: 54318
Summary: [C++11] Bogus "template instantiation depth exceeds
maximum" error + segfault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code:
template
struct wrapped
{
typedef T type;
};
template
typename T::type unwrap1(T);
int unwrap(int);
template
auto unwrap(T t) -> decltype(unwrap(unwrap1(t)))
{
return unwrap(unwrap1(t));
}
int main()
{
unwrap(wrapped>());
}
Seems to produce an infinite loop in GCC, as it displays the same error message
over and over again, and eventualy segfaults.
Here is the error message:
test.cpp:13:6: error: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum) substituting 'template
typename T::type unwrap1(T) [with T = wrapped >]'
auto unwrap(T t) -> decltype(unwrap(unwrap1(t)))
^
test.cpp:13:6: recursively required by substitution of 'template
decltype (unwrap(unwrap1(t))) unwrap(T) [with T = wrapped]'
test.cpp:13:6: required by substitution of 'template decltype
(unwrap(unwrap1(t))) unwrap(T) [with T = wrapped]'
test.cpp:15:29: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum) substituting 'template
typename T::type unwrap1(T) [with T = wrapped >]'
The last 3 lines are repeated thousands of times until finally:
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
I believe the code is valid. Clang compiles it without errors.
[Bug c++/54311] New: Info about default template arguments in instantiation backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54311
Bug #: 54311
Summary: Info about default template arguments in instantiation
backtrace
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following (invalid) code:
template
class A {};
template ::type>
class B {};
int main()
{
B b;
}
GCC's error message is as follows:
test.cpp: In function 'int main()':
test.cpp:10:10: error: no type named 'type' in 'class A'
B b;
^
test.cpp:10:10: error: template argument 2 is invalid
test.cpp:10:13: error: invalid type in declaration before ';' token
B b;
^
Someone looking at this backtrace might be confused as to why A is being
instantiated, as the backtrace doesn't show the line that asks for this
instantiation (that line being "typename U = typename A::type"). The
"template argument 2 is invalid" message provides a hint, but I don't think
it's enough.
I think the error message should be changed to the following:
test.cpp: In function 'int main()':
test.cpp:5:38: error: no type named 'type' in 'class A'
typename U = typename A::type>
^
test.cpp:10:10: required from here
B b;
^
test.cpp:10:13: error: invalid type in declaration before ';' token
B b;
^
[Bug c++/54310] New: Order of operations during overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310
Bug #: 54310
Summary: Order of operations during overload resolution
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
GCC accepts the following code:
template
struct meta
{
typedef typename T::type type;
};
struct S{};
template
typename meta::type foo(T, S);
int foo(int, int);
int main()
{
foo(0, 0);
}
Clang rejects this code with the following error:
test.cpp:4:22: error: type 'int' cannot be used prior to '::' because it has no
members
typedef typename T::type type;
^
test.cpp:10:10: note: in instantiation of template class 'meta' requested
here
typename meta::type foo(T, S);
^
test.cpp:10:24: note: while substituting deduced template arguments into
function template 'foo' [with T = int]
typename meta::type foo(T, S);
^
I believe the code is invalid (and clang's error is correct), for the following
reasons:
1. Template argument deduction should be performed on the template candidate
*before* to discarding it due to a type mismatch for the second parameter
(expected S, got int). Section 13.3.1/7 of the standard says (emphasis mine):
"In each case where a candidate is a function template, candidate function
template specializations are generated using template argument deduction. Those
candidates are *then* handled as candidate functions in the usual way. A given
name can refer to one or more function templates and also to a set of
overloaded non-template functions. In such a case, the candidate functions
generated from each function template are combined with the set of non-template
candidate functions."
2. Template argument deduction on the template candidate should fail with a
hard error (not SFINAE), because the error that occurs (T::type not being valid
for T = int) is not in the immediate context of the function type. (Section
14.8.2/8, emphasis mine: "If a substitution results in an invalid type or
expression, type deduction fails. [...] Only invalid types and expressions *in
the immediate context* of the function type and its template parameter types
can result in a deduction failure. [...]").
GCC does reject the following example:
template
struct meta
{
typedef typename T::type type;
};
template
typename meta::type foo(T);
int foo(int);
int main()
{
foo(0);
}
With the following error:
test.cpp: In instantiation of 'struct meta':
test.cpp:8:24: required by substitution of 'template typename
meta::type foo(T) [with T = int]'
test.cpp:14:10: required from here
test.cpp:4:30: error: 'int' is not a class, struct, or union type
typedef typename T::type type;
^
suggesting that GCC already obeys point (2) above, and therefore the problem is
likely to be with point (1).
[Bug libstdc++/54248] New: Comment in standard library header talks about boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54248 Bug #: 54248 Summary: Comment in standard library header talks about boost Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com This is rather trivial thing, but bits/concept_check.h contains the following comment near the bottom: // Note that the obvious and elegant approach of // //#define glibcxx_function_requires(C) boost::function_requires< boost::C >() // // won't work due to concept templates with more than one parameter, e.g., // BinaryPredicateConcept. The preprocessor tries to split things up on // the commas in the template argument list. We can't use an inner pair of // parenthesis to hide the commas, because "boost::(Temp)" isn't // a valid instantiation pattern. Thus, we steal a feature from C99. Should this comment really be talking about boost?
[Bug libstdc++/54237] New: [C++11] Make more tuple-related functions constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54237 Bug #: 54237 Summary: [C++11] Make more tuple-related functions constexpr Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com Many tuple-related functions are already constexpr (e.g. tuple constructors, get(), tuple_cat(), make_tuple()). I think more of them can be made constexpr, in particular tie() and the comparison operators (operator< and friends).
[Bug c++/54060] G++ warning mixes up anonymous types and anonymous namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54060 --- Comment #2 from Nathan Ridge 2012-07-31 20:21:51 UTC --- What is the purpose of warning about the use of an anonymous type in this context?
[Bug c++/54060] New: [C++11] Lambda expression's type should not be in an anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54060
Bug #: 54060
Summary: [C++11] Lambda expression's type should not be in an
anonymous namespace
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following code, when in a header file:
auto L = [](){};
struct S
{
decltype(L) m;
};
Produces the following warning:
test.hpp:3:8: warning: 'S' has a field 'S::m' whose type uses the anonymous
namespace [enabled by default]
struct S
^
This warning suggests that the type of the lambda is in an anonymous namespace.
A similar warning is given if L is declared at namespace or class scope:
namespace N
{
auto L = [](){};
}
struct S
{
decltype(N::L) m;
};
class N
{
static constexpr auto L = [](){};
};
struct S
{
decltype(N::L) m;
};
According to section 5.1.2/3 of the Standard,
"The type of the lambda-expression (which is also the type of the closure
object) is a unique, unnamed nonunion class type — called the closure type —
whose properties are described below. This class type is not an aggregate
(8.5.1). The closure type is declared in the smallest block scope, class scope,
or namespace scope that contains the corresponding lambda-expression."
This suggests that the types of the lambdas in the above examples should not be
in an anonymous namespace, because that would not be the smallest scope that
contains the lambda-expression.
[Bug libstdc++/53543] New: [unordered_map] conflict with __is_convertible clang intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53543 Bug #: 53543 Summary: [unordered_map] conflict with __is_convertible clang intrinsic Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com The trunk implementation of unordered_map uses the following alias template at class scope: template using __is_convertible = std::is_convertible<_Pair, value_type>; Clang cannot compile this because __is_convertible is a clang intrinsic (much like how __is_base_of is a gcc intrinsic). I asked on the clang mailing list what can be done about this, and they suggested: "Since GCC 4.8 is not yet released, and Clang versions with the __is_convertible intrinsic are, the best solution would be to politely ask the libstdc++ maintainers to change this name." Would it be possible to entertain this request?
[Bug c++/53415] New: problematic error message for ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53415
Bug #: 53415
Summary: problematic error message for ambiguity
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following code:
struct string
{
string(char*);
};
template
void operator+(const string&, const T&);
template
struct S {};
template
struct T
{
enum {value = 0};
};
template
S<0 + T::value> foo(X);
int main()
{
foo(1);
}
Trunk gives the following error message:
test.cpp: In function 'int main()':
test.cpp:23:10: error: no matching function for call to 'foo(int)'
foo(1);
^
test.cpp:23:10: note: candidate is:
test.cpp:19:20: note: template S<(0 + T<
>::value)> foo(X)
S<0 + T::value> foo(X);
^
test.cpp:19:20: note: template argument deduction/substitution failed:
test.cpp: In substitution of 'template S<(0 + T<
>::value)> foo(X) [with X = int]':
test.cpp:23:10: required from here
test.cpp:19:20: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second: [enabled by default]
test.cpp:19:20: note: candidate 1: operator+(int, int)
test.cpp:7:6: note: candidate 2: void operator+(const string&, const T&) [with
T = T::]
void operator+(const string&, const T&);
^
I think there are several problems with this error message:
1. Template argument deduction/substitution is failing because of a *warning*?
The following reduced example:
struct string
{
string(char*);
};
template
void operator+(const string&, const T&);
struct T
{
enum {value = 0};
};
int main()
{
return 0 + T::value;
}
gives a similar warning but no errors. It is inconsistent for an ambiguity to
cause just a warning in one case, and failure of template argument
deduction/substitution in another.
2. There is no caret diagnostic associated with the "ISO C++ says that these
are ambiguous" warning, so it's difficult to tell what "these" are. (We can
infer from the candidates being operator+, but there could have been many uses
of operator+ in that expression, and only one of them ambiguous, so it would be
nice to have a caret pointing to that one).
3. GCC 4.7 compiles the original example fine. Assuming this change in
behaviour is intentional, it should be documented on the 4.8 changes page
because it breaks existing code.
[Bug c++/53336] invalid types in nop conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336
Nathan Ridge changed:
What|Removed |Added
CC||zeratul976 at hotmail dot
||com
--- Comment #1 from Nathan Ridge 2012-05-14
08:50:53 UTC ---
Reduced testcase:
bool foo();
struct C
{
C()
{
if (foo())
foo();
}
};
struct S
{
struct dummy
{
int i_;
};
typedef int dummy::*bool_type;
operator bool_type() const
{
return foo() ? &dummy::i_ : 0;
}
};
int x;
struct adaptor
{
C c;
virtual void bar()
{
if (S())
x = 0;
}
};
int main()
{
adaptor a;
}
Compile with -O2. Errors:
test.cpp: In member function 'virtual void adaptor::bar()':
test.cpp:32:18: error: invalid types in nop conversion
virtual void bar()
^
<<< Unknown tree: offset_type >>>
bool
D.2314_1 = (<<< Unknown tree: offset_type >>>) D.2313_9;
test.cpp:32:18: internal compiler error: verify_gimple failed
[Bug c++/53289] New: unnecessary repetition of caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53289
Bug #: 53289
Summary: unnecessary repetition of caret diagnostics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following (invalid) code:
template
typename T::type g(T);
int main()
{
g(1);
}
The error messages are as follows:
test.cpp: In function 'int main()':
test.cpp:6:8: error: no matching function for call to 'g(int)'
g(1);
^
test.cpp:6:8: note: candidate is:
g(1);
^
test.cpp:2:18: note: template typename T::type g(T)
typename T::type g(T);
^
test.cpp:2:18: note: template argument deduction/substitution failed:
typename T::type g(T);
^
test.cpp: In substitution of 'template typename T::type g(T) [with T =
int]':
test.cpp:6:8: required from here
test.cpp:2:18: error: 'int' is not a class, struct, or union type
typename T::type g(T);
^
The line with the call to g is shown twice; the line with the declaration of g
is shown three times. These repetitions are unnecessary and waste valuable
screen space.
[Bug driver/53286] New: [mingw] improve "CreateProcess: No such file or directory" error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53286 Bug #: 53286 Summary: [mingw] improve "CreateProcess: No such file or directory" error message Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com When running GCC on Windows (MinGW), a wide variety of configuration problems exhibit as a symptom the following error message: CreateProcess: No such file or directory For example, one gets this error when compiling a program if cc1plus.exe is missing or in the wrong directory. This error message is unhelpful because it does not say *which* file was not found; as a result, the underlying configuration problem is difficult to diagnose and resolve. Could this error message be modified to include the name of the file that was not found? For example: CreateProcess: cc1plus.exe: no such file or directory
[Bug c++/53158] New: [C++11] Bogus error in loop condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53158
Bug #: 53158
Summary: [C++11] Bogus error in loop condition
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
int main()
{
auto a = []() { return true; };
auto b = []() { return a(); };
int c, d;
while (b() && c < d)
{
}
}
GCC produces the following errors:
test.cpp: In lambda function:
test.cpp:4:28: error: 'a' is not captured
auto b = []() { return a(); };
^
test.cpp: In function 'int main()':
test.cpp:6:23: error: invalid operands of types 'void' and 'int' to binary
'operator!='
while (b() && c < d)
^
The first error is correct, and fixing it makes both errors go away. However,
the second error is bogus: operator!= is not being called anywhere.
[Bug c++/53152] New: In "no match for operatorXX" error message, mention the types of the arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152
Bug #: 53152
Summary: In "no match for operatorXX" error message, mention
the types of the arguments
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following code:
struct T {};
struct S
{
T foo();
};
int main()
{
S a, b;
a.foo() == b.foo();
}
The error message is:
error: no match for 'operator==' in 'a.S::foo() == b.S::foo()'
Notice the error doesn't mention 'T' anywhere. It would be nice if it did,
because in the general case the arguments passed to the operator could be
arbitrarily complex expressions, and working out their type manually can be
tedious.
[Bug c++/53151] New: [C++11] Incorrect type deduction in conditional expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53151
Bug #: 53151
Summary: [C++11] Incorrect type deduction in conditional
expression
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
According to GCC, the type of T in the following is long:
template U&& declval();
typedef decltype(true ? declval() : declval()) T;
I believe this is incorrect; the correct type of T is long&&
The reasoning is as follows (with sections from N3291):
- Section 5.2.2/10 says that the result of calling a function whose return
type is an rvalue reference to an object type, is an xvalue. This tells us that
declval() is an xvalue.
- Section 5.16/4 says that if the second and third operands to a conditional
expression are glvalues of the same value category and the same type, the
result is of that type and value category. In this case, both operands are
xvalues of the same type, so the whole expression is an xvalue (note that
xvalues are glvalues).
- Finally, section 7.1.6.2/4 says that if e is an xvalue, decltype(e) is T&&
where T is the type of e.
It follows that the type of T should be long&&.
Once this is corrected, an adjustment needs to be made to the implementation of
the binary form of common_type:
template
struct common_type<_Tp, _Up>
{ typedef decltype(true ? declval<_Tp>() : declval<_Up>()) type; };
should become:
template
struct common_type<_Tp, _Up>
{ typedef typename remove_reference() :
declval<_Up>()) type>::type type; };
(The current implementation causes problems when trying to compile standard
library headers with clang, as common_type::type evaluates to
long&& rather than long.)
[Bug c++/52824] New: [C++11] expanding variadic template arguments into non-variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52824
Bug #: 52824
Summary: [C++11] expanding variadic template arguments into
non-variadic template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The fix to PR 35722 fixed many cases of expanding variadic template arguments
into a non-variadic template.
However, the following example (a simple modification of the PR 35722 example,
I just removed the default template arguments from 'foo') gives a bogus error:
template
struct foo
{};
template
struct bar : foo
{};
int main() {
bar f;
}
The error is:
test.cpp:6:22: error: wrong number of template arguments (1, should be 2)
test.cpp:2:8: error: provided for 'template struct foo'
[Bug c++/52748] New: [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Bug #: 52748
Summary: [C++11] N3276 changes to decltype
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The C++11 standard section 5.2.2 pararaph 11 states that:
"If a function call is a prvalue of object type [and] if the function call is
[...] the operand of a decltype-specifier [...], a temporary object is not
introduced for the prvalue. The type of the prvalue may be incomplete. [Note:
as a result, storage is not allocated for the prvalue and it is not destroyed;
thus, a class type is not instantiated as a result of being the type of a
function call in this context."
This addition was made late in the C++11 standardization process; its rationale
is described in the paper N3276 [1]
It seems GCC does not currently support this. In fact, when run on the "trivial
example" given in N3276, GCC gets into an infinite loop and, if left running,
uses up all the memory in the system (!) (Should I file that as a separate
issue?)
Here is the example (WARNING - may exhaust your system's virtual memory if
you're not careful):
template struct S;
template struct pair {};
template S wrap(T) { return 0; }
template
struct S
{
S(int = 0) {}
decltype(wrap(pair())) foo() { return 0; } // ERROR
S > bar() { return 0; } // OK
};
S s;
[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 --- Comment #2 from Nathan Ridge 2012-02-27 16:48:41 UTC --- *Ping* Could this please be fixed for 4.7?
[Bug c++/52145] New: [C++11] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145
Bug #: 52145
Summary: [C++11] zero-valued integer constant expression should
prefer conversion to pointer
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
In the following example:
#include
using std::cerr;
struct S { int n; };
struct X { X(int) {} };
void f(void*)
{
cerr << "Pointer!\n";
}
void f(X)
{
cerr << "X!\n";
}
int main()
{
f(S().n);
}
With GCC 4.7.0-20120128 with the --std=c++11 flag, the output is "X!". The
correct output would be "Pointer!".
The reason is that S's implicit default constructor is constexpr, so it
value-initializes n. Therefore S().n is a zero-valued integer constant
expression, whose conversion to a pointer is preferred over the user-defined
conversion to X.
(This example was taken from Chandler Carruth's talk at the GoingNative 2012
conference.)
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #21 from Nathan Ridge 2012-01-27 19:44:54 UTC --- The testcase and my original program now compile successfully. Thanks!
[Bug libstdc++/52015] New: std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 Bug #: 52015 Summary: std::to_string does not work under MinGW Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com The std::to_string functions are guarded by !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF). MinGW defines this symbol as 1 in its os_defines.h, with a comment pointing to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 That bug was marked as "resolved" over three years ago, but the fix was just to add this guard, not to actually get the functions to work. Can this be fixed so that the to_string functions work on MinGW?
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852
--- Comment #17 from Nathan Ridge 2012-01-27
07:30:00 UTC ---
(In reply to comment #16)
> make check-g++-strict-gc finds failures on several variadic template tests,
> including variadic99.C, so I don't think reducing your testcase is necessary.
Already reduced it :)
It was quite straightforward after using --param gcc-min-heapsize=0 - thanks
Andrew!
Testcase:
template
class transformed {};
template
transformed transform(R r, F f);
template
class joined {};
template
joined join(T t, U u);
template
auto join(T t, U u, V v, Rest... rest) -> decltype(join(join(t, u), v,
rest...));
template
auto polymorphic_transform(F f, Rs... rs) -> decltype(join((transform(rs,
f))...));
int main()
{
polymorphic_transform(0, 0, 0);
}
Compile with:
g++ -c --std=c++0x --param ggc-min-heapsize=0 test.cpp
Output:
'
tree check: expected tree_list, have Hßfè÷þÿø
ÐÝÿÿ¸l in eq_local_specializations, at cp/pt.c:1687
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #15 from Nathan Ridge 2012-01-27 06:29:07 UTC --- (In reply to comment #14) > (In reply to comment #13) > > One thing to do is to use --param ggc-min-expand=1 --param > > ggc-min-heapsize=1 > > and try to reduce it from there. And then when you get down use 0's > > instead of > > 1. That should help with GC issues. > > The error goes away when I add those options! Is that expected? On the other hand, if I add only --param gcc-min-expand=1, there error is still there, and it seems to be much more stable now with respect to small changes in the code. There may be hope for a reduction after all...
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #14 from Nathan Ridge 2012-01-27 05:37:21 UTC --- (In reply to comment #13) > One thing to do is to use --param ggc-min-expand=1 --param ggc-min-heapsize=1 > and try to reduce it from there. And then when you get down use 0's instead > of > 1. That should help with GC issues. The error goes away when I add those options! Is that expected?
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #11 from Nathan Ridge 2012-01-26 21:48:09 UTC --- I bisected the SVN history between the snapshot that worked and the snapshot that gave the error - it appears at r182668.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #10 from Nathan Ridge 2012-01-16 16:12:08 UTC --- (In reply to comment #9) > (In reply to comment #5) > > (In reply to comment #4) > > > >The message "Unhandled dwarf expression opcode 0xf3" stands out > > > That just means the version of gdb you are using does not understand the > > > dwarf2 > > > extensions that GCC is emitting. > > > > > > We really need a preprocessed source to figure out what is going on here. > > > Have > > > you looked into using something like delta? > > > http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction > > > > I can't even get a preprocessed source... when I preprocess the test case > > first > > and then compile it, the error goes away. I only get the error if I do the > > preprocessing and the compilation in the same step. > > This means you probably are using pre-comiled headers? Nope. The symptoms suggest a memory corruption issue, as the error disappears and re-appears with small changes to the code, without any pattern.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #8 from Nathan Ridge 2012-01-14 08:40:35 UTC --- (In reply to comment #6) > (In reply to comment #2) > > you could also try building with --enable-checking=valgrind > > When I try to build gcc with --enable-checking=valgrind, I get the following > error: > > --13242-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a > > valgrind: m_debuginfo/readdwarf.c:2292 (copy_convert_CfiExpr_tree): Assertion > 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. > ==13242==at 0x3802B1F7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) I built valgrind from source and ran cc1plus under valgrind (this is what --enable-checking=valgrind would have done, right?). Attached is the valgrind output. Is there anything helpful in there?
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #7 from Nathan Ridge 2012-01-14 08:39:44 UTC --- Created attachment 26322 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26322 valgrind output
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #6 from Nathan Ridge 2012-01-14 08:06:03 UTC --- (In reply to comment #2) > you could also try building with --enable-checking=valgrind When I try to build gcc with --enable-checking=valgrind, I get the following error: --13242-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a valgrind: m_debuginfo/readdwarf.c:2292 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. ==13242==at 0x3802B1F7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #5 from Nathan Ridge 2012-01-14 07:55:51 UTC --- (In reply to comment #4) > >The message "Unhandled dwarf expression opcode 0xf3" stands out > That just means the version of gdb you are using does not understand the > dwarf2 > extensions that GCC is emitting. > > We really need a preprocessed source to figure out what is going on here. > Have > you looked into using something like delta? > http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction I can't even get a preprocessed source... when I preprocess the test case first and then compile it, the error goes away. I only get the error if I do the preprocessing and the compilation in the same step.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 --- Comment #3 from Nathan Ridge 2012-01-14 07:11:43 UTC --- Here is stack trace of cc1plus at the point where it prints garbage: #0 tree_check_failed (node=0x7fffdc568b40, file=0xf8f214 "../../src/gcc/cp/pt.c", line=1687, function=0xf94cd0 "eq_local_specializations") at ../../src/gcc/tree.c:8822 #1 0x00533f71 in eq_local_specializations (p1=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:1687 #2 eq_local_specializations (p1=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:1685 #3 0x00f7aa4b in htab_find_with_hash (htab=0x2305090, element=0x7fffede2f908, hash=4256980769) at ../../src/libiberty/hashtab.c:606 #4 0x005310b5 in retrieve_local_specialization (tmpl=0x7fffede2f908) at ../../src/gcc/cp/pt.c:1087 #5 0x00562d1e in tsubst_decl (t=0x7fffede2f908, args=0x7fffd78a55a0, complain=3) at ../../src/gcc/cp/pt.c:10396 #6 0x0055ad35 in tsubst (t=0x7fffede2f908, args=0x7fffd78a55a0, complain=3, in_decl=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:4 #7 tsubst (t=0x7fffede2f908, args=0x7fffd78a55a0, complain=3, in_decl=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:11099 #8 0x005625de in tsubst_decl (t=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:10490 #9 0x0055ad35 in tsubst (t=0x7fffede2f990, args=0x7fffd78a55a0, complain=3, in_decl=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:4 #10 tsubst (t=0x7fffede2f990, args=0x7fffd78a55a0, complain=3, in_decl=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:11099 #11 0x0057ea8e in instantiate_decl (d=0x7fffd7c8ac00, defer_ok=, expl_inst_class_mem_p=false) at ../../src/gcc/cp/pt.c:18534 #12 0x005878cc in instantiate_pending_templates (retries=Unhandled dwarf expression opcode 0xf3 ) at ../../src/gcc/cp/pt.c:18828 #13 0x005bebf4 in cp_write_global_declarations () at ../../src/gcc/cp/decl2.c:3763 #14 0x00a3b7cc in compile_file (argc=36, argv=0x7fffe268) at ../../src/gcc/toplev.c:573 #15 do_compile (argc=36, argv=0x7fffe268) at ../../src/gcc/toplev.c:1938 #16 toplev_main (argc=36, argv=0x7fffe268) at ../../src/gcc/toplev.c:2014 #17 0x76f06c4d in __libc_start_main () from /lib/libc.so.6 #18 0x004e3921 in _start () The message "Unhandled dwarf expression opcode 0xf3" stands out - does this help diagnose the problem? I can give values of local variables too if you tell me which ones.
[Bug c++/51852] New: [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852 Bug #: 51852 Summary: [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com A C++11 program that compiled fine with the 2011-11-05 4.7 snapshot, fails to compile with the latest (2012-01-07) snapshot, giving the following error: tree check: expected tree_list, have HßèMÕþÿøtxøtsø º in eq_local_specializations, at cp/pt.c:1687 I have tried to reduce the program to a small test case, unsuccessfully - I've gotten to the point where almost anything I try to remove makes the error go away (and still the program is very long and includes proprietary code so I can't post it). I can keep trying, and I will post the reduced testcase if I succeed, but I thought I'd post the bug in case someone can figure it out just from the error message.
[Bug c++/51277] Feature request: C++ diagnostic for ambiguous overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51277 --- Comment #2 from Nathan Ridge 2011-11-23 16:30:35 UTC --- (In reply to comment #1) > (In reply to comment #0) > > - in the first case, the location of the using-declaration or using- > >directive (if there are several, any one of them should suffice) > > > > > // What I would like to see > > test.cpp: In function 'int main()': > > test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous > > test.cpp:12:9: note: candidates are: > > test.cpp:3:10: note: void n1::foo(double) > > test.cpp:6:13: note: visible in global namespace because of > > using-declaration > > located here > > Should 'global namespace' refer to the scope containing the using-declaration > or the scope containing the ambiguous call? (They're both the global namespace > in your example, but don't have to be.) > A using-directive can also appear at block scope and a using-declaration can > also appear at block scope and class scope, so the note would have to be able > to decide between printing "global namespace" vs "namespace X" vs "current > scope" vs ...? > A using-declaration /declares/ the name in that scope as a synonym for the > other entity, it doesn't just make it visible. A using-directive just makes > the names visible. > To keep the diagnostics simpler maybe the note could just say: > test.cpp:6:13: note: found due to using-declaration here > or > test.cpp:6:13: note: found due to using-directive here > I think that still conveys enough information, without having to worry about > whether it's at namespace scope (and global vs named vs unnamed) or block > scope > or class scope. That would be fine. The key is that the compiler give me the line number where the using declaration/directive is found. (More often than not, the using declaration/directive shouldn't be there, and getting rid of it, or moving it to an appropriate inner scope, resolves the ambiguity, but tracking down a using declaration in a large codebase where a namespace can span hundreds or thousands of files is a huge pain...) > > // What I would like to see > > test.cpp: In function 'int main()': > > test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous > > test.cpp:12:20: note: candidates are: > > test.cpp:8:6: note: void foo(float, n1::Bar) > > test.cpp:5:10: note: void n1::foo(double, n1::Bar) > > test.cpp:3:14: note: found by argument-dependent lookup because second > > argument > > is of type n1::Bar > > Printing "argument 2" is easier than "second argument" (or the diagnostic > machinery needs to be able to print ordinal numbers for any value in any > language!) You're absolutely right, my bad. > Would that note still be useful if it said "is of type X>" ? Yes. The key here is to see the relationship between the argument type and the associated namespace. > What about if it said "is of type Derived" where that type has n1::Bar as an > indirect base class? By the above argument, no. The error should explain why n1 is an associated namespace - in this case by mentioning that n1::Bar is a(n indirect) base class of the argument type. > Would it help to add "so n1 is an associated namespace" or would that make it > too long? > test.cpp:3:14: note: found by argument-dependent lookup because 'n1' is an > associated namespace of argument 2 of type 'n1::Bar' That looks fine, but again, in cases where the relationship is not obvious, (e.g. because the name of the associated namespace does not appear anywhere in the name of the argument type), a note that makes the relationship clear would be helpful. > > Does this sound doable? > > I have no idea :) I'm not familiar with GCC internals, but it seems to me that this is all information the compiler should already have at overload resolution time... it just needs to share it with us!
[Bug c++/51277] New: Feature request: C++ diagnostic for ambiguous overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51277
Bug #: 51277
Summary: Feature request: C++ diagnostic for ambiguous
overloads
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
I have a feature request regarding a compiler diagnostic.
When a call of an overloaded function is ambiguous, and some of the candidates
are declared in namespaces other than the namespace of the call site (or one
of its parent namespaces), it would be helpful if the compiler helped us
figure out why those candidates are visible in the namespace of the call site.
Specifically, it would be helpful if the compiler would say:
- whether the candidate is visible 1) because it was imported into the
namespace of the call site (or one of its parent namespaces) via a
using-declaration or a using-directive, OR 2) because it was found
using argument-dependent lookup
- in the first case, the location of the using-declaration or using-
directive (if there are several, any one of them should suffice)
- in the second case, the argument that triggered the argument-
dependent lookup and why
Examples:
/// EXAMPLE 1 ///
namespace n1
{
void foo(double);
}
using n1::foo;
void foo(float);
int main()
{
foo(0);
}
// Current diagnostic
test.cpp: In function 'int main()':
test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:12:9: note: candidates are:
test.cpp:3:10: note: void n1::foo(double)
test.cpp:8:6: note: void foo(float)
// What I would like to see
test.cpp: In function 'int main()':
test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:12:9: note: candidates are:
test.cpp:3:10: note: void n1::foo(double)
test.cpp:6:13: note: visible in global namespace because of using-declaration
located here
test.cpp:8:6: note: void foo(float)
/// EXAMPLE 2 ///
namespace n1
{
struct Bar {};
void foo(double, Bar);
}
void foo(float, n1::Bar);
int main()
{
foo(n1::Bar());
}
// Current diagnostic
test.cpp: In function 'int main()':
test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous
test.cpp:12:20: note: candidates are:
test.cpp:8:6: note: void foo(float, n1::Bar)
test.cpp:5:10: note: void n1::foo(double, n1::Bar)
// What I would like to see
test.cpp: In function 'int main()':
test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous
test.cpp:12:20: note: candidates are:
test.cpp:8:6: note: void foo(float, n1::Bar)
test.cpp:5:10: note: void n1::foo(double, n1::Bar)
test.cpp:3:14: note: found by argument-dependent lookup because second argument
is of type n1::Bar
//
Does this sound doable?
[Bug libstdc++/44436] [C++0x] Implement emplace* in associative and unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #29 from Nathan Ridge 2011-11-05 20:38:10 UTC --- Should the entry for 23.2.4 on the Library Status page (http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x) not say "Partial" until this is implemented?
[Bug c++/50437] New: [C++0x] [4.7 regression] ICE for trivial use of lambda in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50437
Bug #: 50437
Summary: [C++0x] [4.7 regression] ICE for trivial use of lambda
in template function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following trivial use of a lambda in a template function:
template
void f()
{
auto g = [](T t){ return t == 0; };
g(T());
}
int main()
{
f();
}
Gives the following ICE with GCC 4.7.0-20110910:
test.cpp: In instantiation of 'void f() [with T = int]':
test.cpp:10:12: required from here
test.cpp:5:5: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:459
GCC 4.6.1 compiles the code successfully.
[Bug libstdc++/49836] New: vector::push_back() should not require T to be (move-)assignable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49836
Summary: vector::push_back() should not require T to be
(move-)assignable
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
In the current std::vector implementation, push_back() requires the vector's
element type to be assignable.
For example, in the following code T is copy-constructible but not
copy-assignable, and I attempt to push_back() an T object to a vector:
#include
struct T
{
T() = default;
T(const T&) = default;
T& operator=(const T&) = delete;
};
int main()
{
std::vector v;
T t;
v.push_back(t);
}
And I get the following errors (with --std=c++0x):
In file included from include/c++/4.7.0/vector:70:0,
from test3.cpp:1:
include/c++/4.7.0/bits/vector.tcc: In member function 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with
_Args = {const T&}, _Tp = T, _Alloc = std::allocator, std::vector<_Tp,
_Alloc>::iterator = __gnu_cxx::__normal_iterator >, typename
std::_Vector_base<_Tp, _Alloc>::pointer = T*]':
include/c++/4.7.0/bits/stl_vector.h:905:4: required from 'void
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = T, _Alloc =
std::allocator, std::vector<_Tp, _Alloc>::value_type = T]'
test3.cpp:14:18: required from here
include/c++/4.7.0/bits/vector.tcc:332:4: error: use of deleted function 'T&
T::operator=(const T&)'
test3.cpp:7:8: error: declared here
In file included from include/c++/4.7.0/vector:61:0,
from test3.cpp:1:
include/c++/4.7.0/bits/stl_algobase.h: In static member function 'static _BI2
std::__copy_move_backward::__copy_move_b(_BI1, _BI1, _BI2) [with _BI1 =
T*, _BI2 = T*]':
include/c++/4.7.0/bits/stl_algobase.h:581:18: required from '_BI2
std::__copy_move_backward_a(_BI1, _BI1, _BI2) [with bool _IsMove = true, _BI1 =
T*, _BI2 = T*]'
include/c++/4.7.0/bits/stl_algobase.h:590:34: required from '_BI2
std::__copy_move_backward_a2(_BI1, _BI1, _BI2) [with bool _IsMove = true, _BI1
= T*, _BI2 = T*]'
include/c++/4.7.0/bits/stl_algobase.h:661:15: required from '_BI2
std::move_backward(_BI1, _BI1, _BI2) [with _BI1 = T*, _BI2 = T*]'
include/c++/4.7.0/bits/vector.tcc:326:4: required from 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with
_Args = {const T&}, _Tp = T, _Alloc = std::allocator, std::vector<_Tp,
_Alloc>::iterator = __gnu_cxx::__normal_iterator >, typename
std::_Vector_base<_Tp, _Alloc>::pointer = T*]'
include/c++/4.7.0/bits/stl_vector.h:905:4: required from 'void
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = T, _Alloc =
std::allocator, std::vector<_Tp, _Alloc>::value_type = T]'
test3.cpp:14:18: required from here
include/c++/4.7.0/bits/stl_algobase.h:546:6: error: use of deleted function 'T&
T::operator=(const T&)'
test3.cpp:7:8: error: declared here
A similar problem occurs if I make T move-constructible but not
move-assignable, and try to push_back() an rvalue of type T into the vector.
However, FDIS section 23.2.3/16 specifies that push_back() requires only that T
is CopyInsertable into the vector (or MoveInsertable in the case of the rvalue
version of push_back()).
CopyInsertable is defined in section 23.2.1/13 as the expression
allocator_traits::construct(m, p, v);
being valid (where m is the allocator, p is of type T*, and v is of type T).
For std::allocator, this is just:
::new((void*)p) T(v)
so basically we are requiring T to be copy-constructible (or move-constructible
if v is an rvalue). There is no requirement for T to be copy- or
move-assignable.
The offending statements in the vector implementation (i.e. those which try to
perform assignments) are in the _M_insert_aux helper function (lines 323-333 in
the current trunk):
#ifndef __GXX_EXPERIMENTAL_CXX0X__
_Tp __x_copy = __x;
#endif
_GLIBCXX_MOVE_BACKWARD3(__position.base(),
this->_M_impl._M_finish - 2,
this->_M_impl._M_finish - 1);
#ifndef __GXX_EXPERIMENTAL_CXX0X__
*__position = __x_copy;
#else
*__position = _Tp(std::forward<_Args>(__args)...);
#endif
However, this is in a code path that is not reached from push_back()
(push_back() only calls _M_insert_aux() if _M_impl._M_finish ==
_M_impl._M_end_of_storage, but these statements are in an "if
(this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)" block in
_M_insert_aux()).
(This code path is exercised by other vector functions that call
_M_insert_aux(), such as insert() - and *these* functions *do* require T to be
Copy- or MoveAssignable).
The fix should therefore be simple: duplicate _M_insert_aux() into a separate
version used by push_back() and a separate version used by insert() etc, and
remove the of
[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49003 --- Comment #6 from Nathan Ridge 2011-06-29 21:50:06 UTC --- Thanks Jason! Is there any chance of getting this into 4.6.2?
[Bug c++/49117] New: 4.5 -> 4.6: user-unfriendly change in "invalid conversion" error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49117
Summary: 4.5 -> 4.6: user-unfriendly change in "invalid
conversion" error message
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Consider the following fragment of invalid code:
struct A
{
struct B {};
int g();
B f() { return g(); }
};
GCC 4.5's error message is "error: conversion from 'int' to non-scalar type
'A::B' requested".
GCC 4.6's error message is "error: could not convert 'A::g()' to 'A::B'".
The 4.6 error message no longer mentions the actual type, int, that
cannot be converted to the declared return type, insteading mentioning
the expression yielding that type, A::g().
I think 4.5's error message is more useful because you can see from it
exactly what conversion (int to A::B) is failing. With 4.6's error message,
to find out why the conversion is failing you now have to look up the
return value of A::g() in your code.
The difference becomes more pronounced with more complex examples.
For example, for the code in PR 49003,
GCC 4.5: "error: conversion from 'vector::const_iterator' to non-scalar type
'vector::iterator' requested"
GCC 4.6: "error: could not convert '((const
block*)this)->block::v.vector::begin()' to 'vector::iterator'"
Quite clearly, the 4.5 error message is better.
Having said that, I think the phrasing of the 4.6 error is better.
I think for 4.7, the error message should keep the 4.6 phrasing, but go back to
the 4.5 way of mentioning the type being converted from.
For example:
error: could not convert 'int' to 'A::B'".
or:
error: could not convert 'vector::const_iterator' to 'vector::iterator'
[Bug c++/49003] New: [C++0x] decltype in member function's trailing return type should deduce constness of *this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49003
Summary: [C++0x] decltype in member function's trailing return
type should deduce constness of *this
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Now that the resolution of issue #1207
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1207) made it
into the standard, the following example (taken from the same page) should
compile:
struct vector {
struct iterator { };
struct const_iterator { };
iterator begin();
const_iterator begin() const;
};
class block {
vector v;
auto end() const -> decltype(v.begin()) { return v.begin(); }
};
Currently, GCC gives the same error as before:
test.cpp: In member function ‘vector::iterator block::end() const’:
test.cpp:9:66: error: could not convert ‘((const
block*)this)->block::v.vector::begin()’ to ‘vector::iterator’
[Bug c++/48994] New: error for trivial use of range-based 'for'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48994
Summary: error for trivial use of range-based 'for'
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
GCC trunk (r173706) gives an error for the following trivial use of range-based
'for':
#include
void f(const std::vector& v)
{
for (int i : v)
;
}
The error is:
test.cpp: In function ‘void f(const std::vector&)’:
test.cpp:5:18: error: range-based ‘for’ expression of type ‘const
std::vector’ has incomplete type
The error goes away if I change the function to take the vector by value rather
than reference.
GCC 4.6 compiles the code fine.
[Bug c++/48994] [4.7 regression] error for trivial use of range-based 'for'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48994
--- Comment #1 from Nathan Ridge 2011-05-13
23:19:32 UTC ---
Further reduced to:
template
struct myvec
{
T* begin() const;
T* end() const;
};
void f(const myvec& v)
{
for (int i : v)
;
}
[Bug c++/48409] New: const qualifier for function type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48409 Summary: const qualifier for function type Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com GCC compiles the following code without error: template struct S; template <> struct S; template <> struct S; I believe this code is invalid. Both Comeau C++ and clang give the following error for it: error: type qualifier is not allowed on this function struct S;
[Bug c++/48292] [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292
--- Comment #2 from Nathan Ridge 2011-03-26
00:02:32 UTC ---
Found a workaround:
#include
template
int g(Args...);
template
struct deduce
{
typedef decltype(g(std::declval()...)) type;
};
template
struct A
{
template
static typename deduce::type f(Args... args);
};
int main()
{
A<>::f();
return 0;
}
[Bug c++/48292] [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292 --- Comment #1 from Nathan Ridge 2011-03-25 23:52:22 UTC --- Also, does someone know a workaround for this?
[Bug c++/48292] New: [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292
Summary: [C++0x] "sorry, unimplemented: use of
'type_pack_expansion' in template"
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
template int g(Args...);
template
struct A
{
template
static auto f(Args... args) -> decltype(g(args...));
};
int main()
{
A<>::f();
return 0;
}
gcc gives the following errors:
test.cpp: In function 'int main()':
test.cpp:7:27: sorry, unimplemented: use of 'type_pack_expansion' in template
test.cpp:12:12: error: no matching function for call to 'A<>::f()'
test.cpp:12:12: note: candidate is:
test.cpp:7:55: note: template static decltype (g(A::f::args
...)) A::f(Args ...) [with Args = {Args ...}, int N = 0, decltype (g(A::f::args
...)) = int]
Are there any plans to implement this?
[Bug c++/47336] New: ICE: "Error reporting routines re-entered"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47336
Summary: ICE: "Error reporting routines re-entered"
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
struct A
{
template
struct B
{
};
template
B f(T t)
{
return B();
}
};
template
auto g(T t) -> decltype(A().f(t))
{
return A().f(t);
}
template
class C
{
struct D
{
};
D d;
public:
decltype(g(d)) h()
{
return g(d);
}
};
void g()
{
C c;
c.h();
}
Both gcc 4.5 and 4.6 give the following error:
test.cpp: In instantiation of ‘decltype (A().A::B A::f(t))
g(T) [with T = C::D, decltype (A().A::f(t)) = A::B::D>]’:
Internal compiler error: Error reporting routines re-entered.
As far as I can tell, this is valid C++0x code.
[Bug c++/47335] New: "sorry, unimplemented: mangling overload"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47335
Summary: "sorry, unimplemented: mangling overload"
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
struct A
{
template
int f(T);
};
template
auto g(T x) -> decltype(A().f(x));
void h() { g(0); }
gcc trunk gives the error:
test.cpp: In function ‘void h()’:
test.cpp:10: sorry, unimplemented: mangling overload
As far as I can tell, this is valid C++0x code.
Are there any plans to implement this? I wasn't able to find an existing bug
about it.
[Bug c++/47184] New: gcc interprets C++0x initialization construct as function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47184
Summary: gcc interprets C++0x initialization construct as
function declaration
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}
gcc 4.6 trunk gives the following errors (with the --std=c++0x option):
decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{'
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token
It seems gcc is interpreting the statement as a function declaration.
I think this is valid C++0x.
