[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=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] 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 stdint.h 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++/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 zeratul976 at hotmail dot com --- By comparison, clang's error is: test.cpp:1:14: error: unknown type name 'uint32_t' 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 zeratul976 at hotmail dot com --- (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 zeratul976 at hotmail dot com --- 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 zeratul976 at hotmail dot com --- Richard Smith has suggested that GCC is actually allowed not to instantiate 'metaint' 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 'metaint' 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 zeratul976 at hotmail dot com --- (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++/54318] [C++11] Bogus template instantiation depth exceeds maximum error + segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54318 Nathan Ridge zeratul976 at hotmail dot com changed: What|Removed |Added Version|4.8.0 |4.7.3 --- Comment #1 from Nathan Ridge zeratul976 at hotmail dot com 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++/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 zeratul976 at hotmail dot com 2013-05-02 21:12:27 UTC --- This seems to be fixed in the 4.8.0 release. Close?
[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 zeratul976 at hotmail dot com 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 int struct A; template typename T struct B : Asizeof(T) {}; template typename F Btypename F::type operator-(F); template typename T struct S { struct F { typedef S type; }; auto foo() - decltype(-F()); }; int main() { Sint s; } test.cpp: In instantiation of 'struct BSint ': test.cpp:16:28: required from 'struct Sint' test.cpp:21:12: required from here test.cpp:3:42: error: invalid application of 'sizeof' to incomplete type 'Sint' template typename T struct B : Asizeof(T) {}; ^ Tested with r197837.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Nathan Ridge zeratul976 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #17 from Nathan Ridge zeratul976 at hotmail dot com 2013-04-12 07:23:07 UTC --- (Sorry, meant to reopen with last comment.)
[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 zeratul976 at hotmail dot com 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++/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 iostream namespace N { struct A { int operator+(const void*) { return 42; } }; } namespace M { struct B { }; } template typename T, typename U 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++/56943] Incorrect two-phase name lookup for operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56943 Nathan Ridge zeratul976 at hotmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Nathan Ridge zeratul976 at hotmail dot com 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++/51577] dependent name lookup finds operator in global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Nathan Ridge zeratul976 at hotmail dot com changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #2 from Nathan Ridge zeratul976 at hotmail dot com 2013-04-13 00:44:58 UTC --- *** Bug 56943 has been marked as a duplicate of this bug. ***
[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 typename T class A { typename T::type b(); }; template typename T, typename U void waldo(T, U); template typename T void bar() { waldo([](AT a){ return a; }, []{}); } int main() { barint(); } GCC 4.9 (r197687) gives the following output: test.cpp: In instantiation of 'class Aint': 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++/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 typename void foo_impl() { int data; auto L = [](){ return data; }; [](){ L(); }(); } void foo() { foo_implint(); } The error is: test.cpp: In instantiation of 'foo_impl() [with template-parameter-1-1 = int]::__lambda1': test.cpp:6:12: required from 'struct foo_impl() [with template-parameter-1-1 = int]::__lambda1' test.cpp:6:19: required from 'void foo_impl() [with template-parameter-1-1 = int]' test.cpp:11:19: required from here test.cpp:5:14: error: uninitialized const member 'foo_impl() [with template-parameter-1-1 = 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++/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 zeratul976 at hotmail dot com 2013-04-10 08:30:23 UTC --- Tested with r197663.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Nathan Ridge zeratul976 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #14 from Nathan Ridge zeratul976 at hotmail dot com 2013-04-10 09:27:10 UTC --- Here is a related example that still fails to compile: template int struct A; template typename T struct B : Asizeof(T) {}; template typename T Btypename T::type 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 BS': test.cpp:15:31: required from here test.cpp:3:42: error: invalid application of 'sizeof' to incomplete type 'S' template typename T struct B : Asizeof(T) {}; ^ 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++/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 typename T struct A { typedef typename T::type type; }; template typename T, typename U = Aint() struct C; template typename T struct CT { }; Cint c; but fails to compile with GCC 4.9 (2013-04-07 snapshot) with the following error: test.cpp: In instantiation of 'struct Aint': 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 Aint, the return type of the function type Aint() 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 zeratul976 at hotmail dot com 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 typename T struct Meow { }; } template struct Foo::Meowint { }; 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 zeratul976 at hotmail dot com 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 #4 from Nathan Ridge zeratul976 at hotmail dot com 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++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #8 from Nathan Ridge zeratul976 at hotmail dot com 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 templatetypename T, typename... Args int f(const T, Args...); templatetypename T 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++/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 class T, class... U void f(T, U...);// #1 template class T 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 #2 from Nathan Ridge zeratul976 at hotmail dot com 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++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #3 from Nathan Ridge zeratul976 at hotmail dot com 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++/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 typename, typename, typename = void, typename = void struct foo {}; int main() { fooint 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) fooint f; ^ test.cpp:2:8: error: provided for 'templateclass, class, class, class 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) fooint f; ^ test.cpp:2:8: error: provided for 'templateclass, class, class, class struct foo' struct foo {}; ^
[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 typename T struct meta { typedef typename T::type type; }; struct S{}; template typename T typename metaT::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 'metaint' requested here typename metaT::type foo(T, S); ^ test.cpp:10:24: note: while substituting deduced template arguments into function template 'foo' [with T = int] typename metaT::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 typename T struct meta { typedef typename T::type type; }; template typename T typename metaT::type foo(T); int foo(int); int main() { foo(0); } With the following error: test.cpp: In instantiation of 'struct metaint': test.cpp:8:24: required by substitution of 'templateclass T 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 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 typename class A {}; template typename T, typename U = typename AT::type class B {}; int main() { Bint 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 Aint' Bint b; ^ test.cpp:10:10: error: template argument 2 is invalid test.cpp:10:13: error: invalid type in declaration before ';' token Bint b; ^ Someone looking at this backtrace might be confused as to why Aint is being instantiated, as the backtrace doesn't show the line that asks for this instantiation (that line being typename U = typename AT::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 Aint' typename U = typename AT::type ^ test.cpp:10:10: required from here Bint b; ^ test.cpp:10:13: error: invalid type in declaration before ';' token Bint b; ^
[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 typename T struct wrapped { typedef T type; }; template typename T typename T::type unwrap1(T); int unwrap(int); template typename T auto unwrap(T t) - decltype(unwrap(unwrap1(t))) { return unwrap(unwrap1(t)); } int main() { unwrap(wrappedwrappedint()); } 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 'templateclass T typename T::type unwrap1(T) [with T = wrappedwrappedint ]' auto unwrap(T t) - decltype(unwrap(unwrap1(t))) ^ test.cpp:13:6: recursively required by substitution of 'templateclass T decltype (unwrap(unwrap1(t))) unwrap(T) [with T = wrappedint]' test.cpp:13:6: required by substitution of 'templateclass T decltype (unwrap(unwrap1(t))) unwrap(T) [with T = wrappedint]' test.cpp:15:29: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) substituting 'templateclass T typename T::type unwrap1(T) [with T = wrappedwrappedint ]' 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 http://gcc.gnu.org/bugs.html for instructions. I believe the code is valid. Clang compiles it without errors.
[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::(TempFoo,Bar) 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 zeratul976 at hotmail dot com 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: templatetypename _Pair 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 typename T void operator+(const string, const T); template int struct S {}; template typename struct T { enum {value = 0}; }; template class X S0 + TX::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: templateclass X S(0 + T template-parameter-1-1 ::value) foo(X) S0 + TX::value foo(X); ^ test.cpp:19:20: note: template argument deduction/substitution failed: test.cpp: In substitution of 'templateclass X S(0 + T template-parameter-1-1 ::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) built-in test.cpp:7:6: note: candidate 2: void operator+(const string, const T) [with T = Tint::anonymous enum] 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 typename T 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 zeratul976 at hotmail dot com changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #1 from Nathan Ridge zeratul976 at hotmail dot com 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 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++/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 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: templateclass T 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 'templateclass T 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 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++/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++/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 typename U U declval(); typedef decltype(true ? declvallong() : declvallong()) 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 declvallong() 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: templatetypename _Tp, typename _Up struct common_type_Tp, _Up { typedef decltype(true ? declval_Tp() : declval_Up()) type; }; should become: templatetypename _Tp, typename _Up struct common_type_Tp, _Up { typedef typename remove_referencedecltype(true ? declval_Tp() : declval_Up()) type::type type; }; (The current implementation causes problems when trying to compile standard library headers with clang, as common_typelong, long::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: templatetypename G, typename H struct foo {}; templatetypename... G struct bar : fooG... {}; int main() { barint, float 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 'templateclass G, class H 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): templateclass T struct S; templateclass X, class Y struct pair {}; templateclass T ST wrap(T) { return 0; } templateclass T struct S { S(int = 0) {} decltype(wrap(pairT,T())) foo() { return 0; } // ERROR SpairT,T bar() { return 0; } // OK }; Sint 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 zeratul976 at hotmail dot com 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 iostream 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 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 #21 from Nathan Ridge zeratul976 at hotmail dot com 2012-01-27 19:44:54 UTC --- The testcase and my original program now compile successfully. Thanks!
[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 zeratul976 at hotmail dot com 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 #14 from Nathan Ridge zeratul976 at hotmail dot com 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 #15 from Nathan Ridge zeratul976 at hotmail dot com 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 #17 from Nathan Ridge zeratul976 at hotmail dot com 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 typename, typename class transformed {}; template class R, class F transformedF, R transform(R r, F f); template typename, typename class joined {}; template typename T, typename U joinedT, U join(T t, U u); template typename T, typename U, typename V, typename... Rest auto join(T t, U u, V v, Rest... rest) - decltype(join(join(t, u), v, rest...)); template typename F, typename... Rs 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 #10 from Nathan Ridge zeratul976 at hotmail dot com 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 #6 from Nathan Ridge zeratul976 at hotmail dot com 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 #7 from Nathan Ridge zeratul976 at hotmail dot com 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 #8 from Nathan Ridge zeratul976 at hotmail dot com 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] 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++/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 zeratul976 at hotmail dot com 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=value optimized out, 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] [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 zeratul976 at hotmail dot com 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++/51277] Feature request: C++ diagnostic for ambiguous overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51277 --- Comment #2 from Nathan Ridge zeratul976 at hotmail dot com 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 XYn1::Bar ? 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 zeratul976 at hotmail dot com changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #29 from Nathan Ridge zeratul976 at hotmail dot com 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 typename T void f() { auto g = [](T t){ return t == 0; }; g(T()); } int main() { fint(); } 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: vectorT::push_back() should not require T to be (move-)assignable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49836 Summary: vectorT::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 vectorT: #include vector struct T { T() = default; T(const T) = default; T operator=(const T) = delete; }; int main() { std::vectorT 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::allocatorT, std::vector_Tp, _Alloc::iterator = __gnu_cxx::__normal_iteratorT*, std::vectorT , 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::allocatorT, 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_backwardtrue, false, std::random_access_iterator_tag::__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::allocatorT, std::vector_Tp, _Alloc::iterator = __gnu_cxx::__normal_iteratorT*, std::vectorT , 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::allocatorT, 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_traitsA::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
[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 zeratul976 at hotmail dot com 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] [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 zeratul976 at hotmail dot com 2011-05-13 23:19:32 UTC --- Further reduced to: template typename T struct myvec { T* begin() const; T* end() const; }; void f(const myvecint v) { for (int i : v) ; }
[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 vector void f(const std::vectorint v) { for (int i : v) ; } The error is: test.cpp: In function ‘void f(const std::vectorint)’: test.cpp:5:18: error: range-based ‘for’ expression of type ‘const std::vectorint’ 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++/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: templatetypename struct S; template struct Svoid(); template struct Svoid() const; 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 Svoid() const;
[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 typename... Args int g(Args...); template int N = 0 struct A { template typename... Args 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: templateclass ... Args 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++/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 zeratul976 at hotmail dot com 2011-03-25 23:52:22 UTC --- Also, does someone know a workaround for this?
[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 zeratul976 at hotmail dot com 2011-03-26 00:02:32 UTC --- Found a workaround: #include type_traits template typename... Args int g(Args...); template typename... Args struct deduce { typedef decltype(g(std::declvalArgs()...)) type; }; template int N = 0 struct A { template typename... Args static typename deduceArgs...::type f(Args... args); }; int main() { A::f(); return 0; }
[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 typename T int f(T); }; template typename T 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++/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 typename T struct B { }; template typename T BT f(T t) { return BT(); } }; template typename T auto g(T t) - decltype(A().f(t)) { return A().f(t); } template typename S class C { struct D { }; D d; public: decltype(g(d)) h() { return g(d); } }; void g() { Cint c; c.h(); } Both gcc 4.5 and 4.6 give the following error: test.cpp: In instantiation of ‘decltype (A().A::BT A::f(t)) g(T) [with T = Cint::D, decltype (A().A::f(t)) = A::BCint::D]’: Internal compiler error: Error reporting routines re-entered. As far as I can tell, this is valid C++0x code.
[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.