[Bug c++/78506] [c++1z] wrong value category for class decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78506 lucdanton at free dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from lucdanton at free dot fr --- This has been fixed at some point.
[Bug c++/80084] New: [7 regression] wrong code for decomposition declaration with debug iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80084 Bug ID: 80084 Summary: [7 regression] wrong code for decomposition declaration with debug iterator Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I managed to reduce to this testcase: // #include #include struct aggr { std::vector::iterator val; }; void decomp(aggr arg) { auto& [val] = arg; // fires assert( &val == &arg.val ); } int main() { // inlined decomp { aggr arg {}; auto& [val] = arg; // fine assert( &val == &arg.val ); } decomp(aggr {}); } //-- The assertion in decomp fires when the program is compiled with e.g.: g++-trunk -std=c++1z main.cpp -D_GLIBCXX_DEBUG According to my bisecting, this change was introduced by r245638.
[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #6 from lucdanton at free dot fr --- As a heads-up, deduction was possible when the constructor was a non-template: std::basic_string_view sv = …; // produces an std::basic_string auto into_string = std::basic_string { sv }; That made it possible to concisely convert a string view to its 'natural' string type, even in a generic context. (Unless I'm mistaken there is nothing in the current basic_string_view interface that would allow to do the same, e.g. sv.to_string().) Now that's it a constrained constructor template, it looks like deduction picks an std::initializer_list constructor. So into_string ends up being an std::basic_string. Of course the only thing that is lost is conciseness, the user can resort to any of several other solutions.
[Bug c++/79503] New: [new inheriting ctors] spurious bad candidate from same or derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79503 Bug ID: 79503 Summary: [new inheriting ctors] spurious bad candidate from same or derived type Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- My understanding of the new inheriting constructor rules is a bit shaky so I may be off here. The testcase: // struct payload {}; struct base: private payload { base(payload) {} }; struct derived: base { using base::base; }; int main() { payload data; // error: no matching function for call to 'derived::derived(payload&)' // note: candidate: base::base(payload) // note: an inherited constructor is not a candidate for initialization from an expression of the same or derived type derived demo(data); } // Compilation fails on recent trunk with e.g.: g++-trunk -std=c++14 main.cpp but succeeds with -fno-new-inheriting-ctors. A hint that something is wrong is that there is no error if base derives from some other class than payload. At the very least the last note is misleading: all inherited candidates are from base whereas the expression has type payload which is neither the same nor derived from it.
[Bug c++/79502] New: [[nodiscard]] attribute ignored for class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79502 Bug ID: 79502 Summary: [[nodiscard]] attribute ignored for class template Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- On r245381, the demonstration program does not complain when compiled. //-- template struct [[nodiscard]] missiles {}; missiles make() { return {}; } int main() { // result value ignored here make(); } //--
[Bug c++/79094] Pack expansion in using-declaration rejects an attempt to inherit a pack of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #1 from lucdanton at free dot fr --- Another case that wants a dependent type expanded alongside the bases, but where the declarator does not name a constructor: template struct unvariadic: private A, private B { // okay, provided A and B each declare appropriate // target_type and operator target_type() members using A::operator typename A::target_type, B::operator typename B::target_type; }; template struct variadic: private Bases... { // error: parameter packs not expanded with '...': using Bases::operator typename Bases::target_type...; };
[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79143 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #1 from lucdanton at free dot fr --- If it's any help in solving this, the regression only manifests when derived publicly inherits from its base.
[Bug c++/78591] New: [c++1z] ICE when using decomposition identifier from closure object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78591 Bug ID: 78591 Summary: [c++1z] ICE when using decomposition identifier from closure object Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I'm not entirely sure is the ice-on-invalid tag is warranted here. $ g++-trunk -std=c++1z main.cpp main.cpp: In function 'int main()': main.cpp:5:12: internal compiler error: Segmentation fault return insides; ^~~ 0xb6cebf crash_signal ../../gcc/gcc/toplev.c:333 0x8e996d expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10108 0x8f4470 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/gcc/expr.c:5551 0x8f535f expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5320 0x808dbe expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3641 0x808dbe expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3737 0x80aa30 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5744 0x80f746 execute ../../gcc/gcc/cfgexpand.c:6358 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. The program: //-- int main() { int i = 0; auto [insides] = [&i] {}; return insides; }
[Bug c++/78506] New: [c++1z] wrong value category for class decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78506 Bug ID: 78506 Summary: [c++1z] wrong value category for class decomposition Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The spec and intent looks straightforward to me, i should be an lvalue. //-- struct one { int i; }; int main() { auto&& [i] = one {}; // error: taking address of xvalue (rvalue reference) &i; }
[Bug c++/78495] New: [7 regression][new inheriting ctors] variant members lead to uninitialized parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78495 Bug ID: 78495 Summary: [7 regression][new inheriting ctors] variant members lead to uninitialized parameter Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I noticed an std::unique_ptr destructor was being called on a bogus pointer in an own::optional> testcase of mine (not std::optional/libstdc++-related). I managed to reduce to a minimal test and in the debugger it looks like when the inherited constructor is entered the val parameter contains garbage. Then upon leaving the constructor the destructor for the parameter is run on that garbage. Whatever the exact rundown of events, the regression is that the program used to return 0 whereas it returns 1 now. The change in behaviour appeared with r241765. From then on, compiling the testcase with -fnew-inheriting-ctors gives the new behaviour while -fno-new-inheriting-ctors gives the old for both -std=c++1z and -std=c++14. //-- int counter = 0; struct canary { canary() {} bool active = false; canary(canary const&) = delete; canary(canary&& other): active(other.active) { other.active = false; } ~canary() { if(active) ++counter; } }; struct optional_base { union { unsigned char empty {}; canary val; }; bool active = false; optional_base(canary val) : val(static_cast(val)) , active(true) {} ~optional_base() { if(active) { val.~canary(); } } }; struct optional: optional_base { using optional_base::optional_base; }; int main() { { // N.B. inactive from the start canary c; //assert( !c.active ); optional o(static_cast(c)); //assert( !c.active ); // may fire if -O level above 0 //assert( !o.val.active ); } return counter; }
[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124 --- Comment #2 from lucdanton at free dot fr --- I ran into a different program that regressed starting at r241187 (again, only for -std=c++1z), this time not involving explicit constructors: //-- struct aggr { int x; }; struct base { base(aggr) {} }; struct derived: base { using base::base; }; base fine() { return { { 0 } }; } // error: could not convert '{{0}}' from '' to 'derived' derived uhoh() { return { { 0 } }; } int main() { }
[Bug c++/78361] New: [7 regression][c++1z] std::__is_referenceable doesn't handle noexcept function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78361 Bug ID: 78361 Summary: [7 regression][c++1z] std::__is_referenceable doesn't handle noexcept function types Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 40042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40042&action=edit untested patch Currently on trunk __is_referenceable doesn't seem to handle noexcept function types. This then carries over to e.g. std::add_pointer and then in turn to std::decay_t, ultimately causing regressions for code like std::make_tuple(std::free). It might be instructive to grep for 6 dots (e.g. '\.\{6\}') to try and catch all those partial specializations that handle function types, and update them. If I ape what is_function does that fixes the regression on my end, but other than that I have not run the tests and in any case I don't know if it's the right fix. It's attached as a patch.
[Bug c++/78139] New: [7 regression][c++1z] inaccessible destructor required in new expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78139 Bug ID: 78139 Summary: [7 regression][c++1z] inaccessible destructor required in new expression Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- While trying to compile Boost.Locale with trunk in C++1z mode I ran into the following regression (simplified): // error: 'std::__cxx11::collate_byname<_CharT>::~collate_byname() [with _CharT = char]' is protected within this context std::locale loc2 = std::locale(std::locale(), new std::collate_byname("")); I tried to convert it to a minimal testcase to bisect the regression but unfortunately I unwittingly ran into PR57082. Using a not-so-minimal testcase instead, I bisected to r240889. The program: //-- #include int main() { // all fine std::locale loc0(std::locale(), new std::collate_byname("")); std::locale loc1 = { std::locale(), new std::collate_byname("") }; // error: 'std::__cxx11::collate_byname<_CharT>::~collate_byname() [with _CharT = char]' is protected within this context std::locale loc2 = std::locale(std::locale(), new std::collate_byname("")); }
[Bug c++/57082] brace initialization requires public destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #1 from lucdanton at free dot fr --- Using a very similar testcase I bisected the issue to r239783: //-- struct no_destr { no_destr() = default; protected: ~no_destr() = default; }; int main() { // error: 'no_destr::~no_destr()' is protected within this context new no_destr {}; }
[Bug c++/78124] New: [7 regression][c++1z] explicit inheriting constructor is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124 Bug ID: 78124 Summary: [7 regression][c++1z] explicit inheriting constructor is ignored Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I have bisected this regression to r241188. The program fails to compile in C++1z mode on trunk, yielding this: $ g++-trunk -std=c++1z main.cpp main.cpp: In function 'int main()': main.cpp:11:19: error: could not convert '0' from 'int' to 'base' derived d { 0 }; The testcase: //-- struct base { explicit constexpr base(int&&) {} }; struct derived: base { using base::base; }; int main() { derived d { 0 }; } //--
[Bug c++/78073] inherited initializer_list constructor is not accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78073 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #1 from lucdanton at free dot fr --- Bisected to r241187.
[Bug c++/68372] [concepts] invalid use of pack expansion expression in member function template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372 --- Comment #1 from lucdanton at free dot fr --- On 7 trunk (rev. 239680) it looks like the program now triggers an ICE: $ g++-trunk -std=c++1z -fconcepts main.cpp main.cpp: In substitution of 'template requires C... void foo::bar(X ...) [with X = {}]': main.cpp:18:16: required from here main.cpp:11:10: internal compiler error: in tsubst_constraint, at cp/constraint.cc:1957 void bar(X...) ^~~ 0x764263 tsubst_constraint(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/constraint.cc:1957 0x764362 tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/constraint.cc:1919 0x661f65 tsubst_decl ../../gcc/gcc/cp/pt.c:11967 0x667834 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:12907 0x670290 instantiate_template_1 ../../gcc/gcc/cp/pt.c:17558 0x670290 instantiate_template(tree_node*, tree_node*, int) ../../gcc/gcc/cp/pt.c:17609 0x67701a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool) ../../gcc/gcc/cp/pt.c:17984 0x62a048 add_template_candidate_real ../../gcc/gcc/cp/call.c:3119 0x62a813 add_template_candidate ../../gcc/gcc/cp/call.c:3197 0x62a813 add_candidates ../../gcc/gcc/cp/call.c:5384 0x62afe5 build_new_method_call_1 ../../gcc/gcc/cp/call.c:8421 0x62afe5 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8620 0x6bb668 cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6908 0x6b9832 cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:8019 0x6c1787 cp_parser_cast_expression ../../gcc/gcc/cp/parser.c:8696 0x6c1d53 cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8797 0x6c2434 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:9084 0x6c48aa cp_parser_expression ../../gcc/gcc/cp/parser.c:9253 0x6c4e8f cp_parser_expression_statement ../../gcc/gcc/cp/parser.c:10736 0x6d17d4 cp_parser_statement ../../gcc/gcc/cp/parser.c:10587
[Bug c++/77337] New: [7 regression][c++1z] use before deduction of 'auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77337 Bug ID: 77337 Summary: [7 regression][c++1z] use before deduction of 'auto' Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The included program compiles on 6.1 and I think on the 6.2 branch (I would need definite confirmation however), with either -std=c++14 or -std=c++1z. On 7 trunk (rev. 239676) it compiles as well with the following: $ g++-trunk -std=c++14 main.cpp but it fails in c++1z mode: $ g++-trunk -std=c++1z main.cpp main.cpp: In instantiation of 'main():: [with auto:1 = fix_type >]': main.cpp:6:27: required from 'decltype(auto) fix_type::operator()() [with Functor = main()::]' main.cpp:25:17: required from here main.cpp:21:17: error: use of 'decltype(auto) fix_type::operator()() [with Functor = main()::]' before deduction of 'auto' self(); ^~ I'm not 100% sure that GCC should accept the program though. FWIW Clang accepts it. //-- template struct fix_type { Functor functor; decltype(auto) operator()() { return functor(*this); } }; template fix_type fix(Functor functor) { return { functor }; } int main() { auto zero = fix( [](auto& self) -> int // N.B. non-deduced, non-dependent return type { return 0; // error: use of 'decltype(auto) fix_type::operator()() [with Functor = main()::]' before deduction of 'auto' self(); } ); return zero(); }
[Bug c++/68437] [concepts] fold expression, pack expansion, and deduced constraint requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437 --- Comment #1 from lucdanton at free dot fr --- This compiles using tip of the trunk. Presumably the concepts overhaul took care of it.
[Bug c++/73456] New: [7 regression][concepts] ICE in non_atomic_constraint_p, at cp/logic.cc:315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73456 Bug ID: 73456 Summary: [7 regression][concepts] ICE in non_atomic_constraint_p, at cp/logic.cc:315 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Using the following program: //-- template struct list {}; template concept bool Sequence = true; template struct zip {}; template requires requires { typename list; } // main.cpp:12:8: internal compiler error: in non_atomic_constraint_p, at cp/logic.cc:315 struct zip {}; int main() { zip, list> {}; } //-- This compiles fine with 6.1, but produces the following trace on the 7 branch on rev. 239343: main.cpp:12:8: internal compiler error: in non_atomic_constraint_p, at cp/logic.cc:315 struct zip {}; ^~~~ 0x76550a non_atomic_constraint_p ../../gcc/gcc/cp/logic.cc:315 0x767364 any_p, bool (*)(tree_node*)> ../../gcc/gcc/cp/logic.cc:67 0x767364 any_non_atomic_constraints_p ../../gcc/gcc/cp/logic.cc:324 0x767364 analyze_atom ../../gcc/gcc/cp/logic.cc:356 0x767364 analyze_term ../../gcc/gcc/cp/logic.cc:465 0x767364 check_term ../../gcc/gcc/cp/logic.cc:492 0x766966 check_goal ../../gcc/gcc/cp/logic.cc:508 0x766966 check_proof ../../gcc/gcc/cp/logic.cc:534 0x766966 prove_implication ../../gcc/gcc/cp/logic.cc:751 0x7674a1 prove_implication ../../gcc/gcc/cp/logic.cc:728 0x7674a1 subsumes_constraints_nonnull ../../gcc/gcc/cp/logic.cc:783 0x7674a1 subsumes(tree_node*, tree_node*) ../../gcc/gcc/cp/logic.cc:800 0x76530f strictly_subsumes(tree_node*, tree_node*) ../../gcc/gcc/cp/constraint.cc:2595 0x67479d process_partial_specialization ../../gcc/gcc/cp/pt.c:4541 0x674ea7 push_template_decl_real(tree_node*, bool) ../../gcc/gcc/cp/pt.c:5262 0x675f73 push_template_decl(tree_node*) ../../gcc/gcc/cp/pt.c:5503 0x675f73 maybe_process_partial_specialization(tree_node*) ../../gcc/gcc/cp/pt.c:972 0x6b7f84 cp_parser_class_head ../../gcc/gcc/cp/parser.c:22075 0x6b7f84 cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:21431 0x6b7f84 cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:21741
[Bug c++/72415] [7 regression][concepts] ICE in satisfy_predicate_constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415 --- Comment #2 from lucdanton at free dot fr --- I completely failed to make note that this used to compile on GCC 6.1, too (modulo the missing definition, again).
[Bug c++/72415] New: [concepts] ICE in satisfy_predicate_constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415 Bug ID: 72415 Summary: [concepts] ICE in satisfy_predicate_constraint Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Using rev. 238737 with the following minimal testcase: //-- template struct indices {}; template struct foo_type { template static void impl(indices) requires (... && (Indices, true)); static auto caller() { return impl(indices<0, 1, 2> {}); } }; int main() { // internal compiler error: in satisfy_predicate_constraint, at cp/constraint.cc:2013 foo_type::caller(); } //-- Compiling with e.g. 'g++-trunk -std=c++1z -fconcepts main.cpp' ICEs with a trace (at the end of the report). On rev. 238124 the code behaves as expected, i.e. compiles without linking due to the missing definition. main.cpp: In instantiation of 'static auto foo_type::caller() [with Dummy = void]': main.cpp:17:21: required from here main.cpp:11:18: internal compiler error: in satisfy_predicate_constraint, at cp/constraint.cc:2013 { return impl(indices<0, 1, 2> {}); } ^ 0x761a1f satisfy_predicate_constraint ../../gcc/gcc/cp/constraint.cc:2013 0x761a1f satisfy_constraint_1 ../../gcc/gcc/cp/constraint.cc:2245 0x761add satisfy_constraint ../../gcc/gcc/cp/constraint.cc:2303 0x761b93 satisfy_associated_constraints ../../gcc/gcc/cp/constraint.cc:2327 0x761caf constraints_satisfied_p(tree_node*) ../../gcc/gcc/cp/constraint.cc:2402 0x627a96 add_function_candidate ../../gcc/gcc/cp/call.c:2016 0x6285ba add_template_candidate_real ../../gcc/gcc/cp/call.c:3149 0x628a23 add_template_candidate ../../gcc/gcc/cp/call.c:3191 0x628a23 add_candidates ../../gcc/gcc/cp/call.c:5378 0x6291f5 build_new_method_call_1 ../../gcc/gcc/cp/call.c:8414 0x6291f5 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8613 0x708de3 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2390 0x664193 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:16746 0x65d957 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:15918 0x65d87d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:15226 0x65d845 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:15401 0x65bfb0 instantiate_decl(tree_node*, int, bool) ../../gcc/gcc/cp/pt.c:22148 0x697d6b maybe_instantiate_decl ../../gcc/gcc/cp/decl2.c:5088 0x699320 mark_used(tree_node*, int) ../../gcc/gcc/cp/decl2.c:5187 0x70c54b finish_qualified_id_expr(tree_node*, tree_node*, bool, bool, bool, bool, int) ../../gcc/gcc/cp/semantics.c:1956
[Bug c++/71808] New: [concepts] ICE in finish_member_declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71808 Bug ID: 71808 Summary: [concepts] ICE in finish_member_declaration Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- ICE on both 6.1 and 7 trunk (rev. 238124), although I can't verify if the stacktraces are similar. I don't know if the code should be rejected or not. $ cat main.cpp template concept bool Fooable = requires(X x) { x.foo(); }; Fooable{X} struct container { using member_type = typename X::member_type; X payload; }; template struct model { using member_type = X; void foo() {} container> bar() { return {}; } }; int main() { container> {}.payload.bar(); } $ g++-trunk -std=c++1z -fconcepts main.cpp main.cpp: In instantiation of 'struct container >': main.cpp:22:42: required from here main.cpp:5:18: internal compiler error: in finish_member_declaration, at cp/semantics.c:2949 struct container { ^ 0x7032d9 finish_member_declaration(tree_node*) ../../gcc/gcc/cp/semantics.c:2949 0x674916 instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:10203 0x674916 instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:10417 0x6d682d complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:133 0x6d68d4 complete_type_or_maybe_complain(tree_node*, tree_node*, int) ../../gcc/gcc/cp/typeck.c:145 0x6d69b1 require_complete_type_sfinae(tree_node*, int) ../../gcc/gcc/cp/typeck.c:89 0x61e969 build_cxx_call(tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:7920 0x628c13 build_over_call ../../gcc/gcc/cp/call.c:7831 0x627694 build_new_method_call_1 ../../gcc/gcc/cp/call.c:8521 0x627694 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8591 0x6b3f78 cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6880 0x6b2142 cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7991 0x6ba157 cp_parser_cast_expression ../../gcc/gcc/cp/parser.c:8668 0x6ba723 cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8769 0x6bae04 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:9056 0x6bd27a cp_parser_expression ../../gcc/gcc/cp/parser.c:9225 0x6bd85f cp_parser_expression_statement ../../gcc/gcc/cp/parser.c:10686 0x6c9a83 cp_parser_statement ../../gcc/gcc/cp/parser.c:10537 0x6ca2fc cp_parser_statement_seq_opt ../../gcc/gcc/cp/parser.c:10809 0x6ca3df cp_parser_compound_statement ../../gcc/gcc/cp/parser.c:10763
[Bug c++/71368] New: [concepts] ICE on constrained compound requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71368 Bug ID: 71368 Summary: [concepts] ICE on constrained compound requirement Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The following produces an ICE on both GCC 6.1 and trunk (rev. 236974): $ cat main.cpp struct inner; template concept bool CompoundReq = requires { // fine with concrete type in trailing type, i.e. inner& instead of X& { X::inner_member() } -> X&; }; template concept bool Concept = requires { { X::outer_member() } -> CompoundReq; }; struct inner { static inner& inner_member(); }; struct outer { static inner outer_member(); }; int main() { // fine static_assert( CompoundReq ); static_assert( CompoundReq ); // ICE static_assert( Concept ); } $ g++-trunk -std=c++1z -fconcepts main.cpp g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
[Bug c++/71285] New: [7 regression] spurious 'insufficient contextual information' for member access on fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71285 Bug ID: 71285 Summary: [7 regression] spurious 'insufficient contextual information' for member access on fold expression Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- On rev. 236761 it looks like performing member access on a fold expression produces an 'insufficient contextual information to determine type' error, even before instantiation. Example: $ cat main.cpp template void spurious(Args... args) { (... + args).member; } int main() { } $ g++-trunk -std=c++1z main.cpp main.cpp: In function 'void spurious(Args ...)': main.cpp:4:17: error: insufficient contextual information to determine type (... + args).member; ^
[Bug c++/70827] New: [6 regression] dubious use of deleted function in inherited constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70827 Bug ID: 70827 Summary: [6 regression] dubious use of deleted function in inherited constructor Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- struct move_only { move_only() = default; move_only(move_only&&) = default; }; struct base { base(move_only) {} }; struct derived: base { // error: use of deleted function 'constexpr move_only::move_only(const move_only&)' using base::base; }; int main() { // note: synthesized method 'derived::derived(move_only)' first required here derived h(move_only {}); } = Using GCC 6.1: $ g++-trunk --version g++-trunk (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-trunk -std=c++11 main.cpp main.cpp: In constructor 'derived::derived(move_only)': main.cpp:12:17: error: use of deleted function 'constexpr move_only::move_only(const move_only&)' using base::base; ^~~~ main.cpp:1:8: note: 'constexpr move_only::move_only(const move_only&)' is implicitly declared as deleted because 'move_only' declares a move constructor or move assignment operator struct move_only { ^ main.cpp: In function 'int main()': main.cpp:18:27: note: synthesized method 'derived::derived(move_only)' first required here derived h(move_only {}); = The program compiles fine with 5.3.1, earlier 6 snapshots, and Clang.
[Bug c++/70808] New: Spurious -Wzero-as-null-pointer-constant for nullptr_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70808 Bug ID: 70808 Summary: Spurious -Wzero-as-null-pointer-constant for nullptr_t Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The following program emits a warning when compiled with -Wzero-as-null-pointer-constant: int main() { int* no_warn = {}; // main.cpp:5:33: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] decltype( nullptr ) warn = {}; } Unless I'm mistaken, this is not intended as demonstrated by the innocuous no_warn variable. Happens on a variety of versions, e.g. 5.3.1 and 6, as well as multiple -std settings, e.g. c++11 and c++1z.
[Bug c++/69731] New: Inconsistent SFINAE in interaction with variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69731 Bug ID: 69731 Summary: Inconsistent SFINAE in interaction with variable templates Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 37641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37641&action=edit Minimal testcase It appears that GCC behaves differently depending on how SFINAE is performed (e.g. how a trait is written), and how a trait is used(!) at the constraint site (using regular enable_if_t techniques). In one particular case one of the techniques loops until the instantiation limit depth is reached, but only if the short form is used on the site. Regardless of what /should/ happen (which I have no idea about), I believe GCC should consistently either loop or terminate. For what it's worth Clang accepts all cases for both forms. I am using 6.0.0 20160208, the testcase is compiled with alternatively: g++-trunk -std=c++1z -DSHORT testcase.cpp g++-trunk -std=c++1z testcase.cpp The first command results in constraints that use trait_v variable templates and succeeds. The second command results in constraints that use the trait::value static members and hits the limit.
[Bug c++/69718] New: [concepts] cc1plus segfault on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69718 Bug ID: 69718 Summary: [concepts] cc1plus segfault on invalid Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The testcase was mechanically reduced. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20160208 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp template concept bool Concept = requires { Type { 0 }; }; struct foo { typename foo(Init) requires Concept { foo { $ g++-trunk -std=c++1z main.cpp main.cpp:3:14: error: expected nested-name-specifier before 'foo' typename foo(Init) requires Concept { ^~~ main.cpp:3:18: error: 'Init' has not been declared typename foo(Init) requires Concept { ^~~~ main.cpp:4:13: error: expected '}' at end of input foo { ^ g++-trunk: 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.
[Bug c++/69472] New: [concepts] constraint ignored on constrained member template of a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69472 Bug ID: 69472 Summary: [concepts] constraint ignored on constrained member template of a class template Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- PR69288 may be related as it also observes some differences in how a constrained template behaves depending on whether it is a member template of a class template or not. On the other hand it involves an ambiguity and a non-dependent template parameter, whereas this does not. Although I should point out that the actual code I produced this testcase from did originally exhibit an ambiguity. Using 6.0.0 20160122, testcase compiled with: g++-trunk -std=c++1z main.cpp results in: main.cpp: In instantiation of 'struct enclosing::member': main.cpp:35:35: required from here main.cpp:25:9: error: static assertion failed Full testcase: template constexpr bool foo = true; template<> constexpr bool foo = false; template struct non_member {}; template requires foo struct non_member { static_assert( foo ); }; template struct enclosing { template struct member {}; template requires foo struct member { // error: static_assertion failed static_assert( foo ); }; }; int main() { // fine non_member {}; // blows up enclosing::member {}; }
[Bug c++/69470] New: [concepts] bogus constrained member class template redeclared with different access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69470 Bug ID: 69470 Summary: [concepts] bogus constrained member class template redeclared with different access Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Using 6.0.0 20160122, testcase compiled with: g++-trunk -std=c++1z main.cpp results in: main.cpp:13:5: error: 'struct foo<0, T>' redeclared with different access Full testcase: struct enclosing { private: template struct foo {}; template requires false struct foo<0, T> {}; template requires true // error: 'struct foo<0, T>' redeclared with different access struct foo<0, T> {}; }; int main() { }
[Bug c++/69189] New: [concepts] ICE: segmentation fault in instantiate_template_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69189 Bug ID: 69189 Summary: [concepts] ICE: segmentation fault in instantiate_template_1 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 37262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37262&action=edit Preprocessed source Mechanically reduced preprocessed source attached. This is using 6.0.0 20160107, compiled with: g++-trunk -std=c++1z prepro.ii Error & stacktrace: prepro.ii: In substitution of 'template {anonymous}::any_base::any_base(Value&&) requires predicate( ::no_special_members_interference<::any_base, Value>::value) [with Value = {anonymous}::any_base]': prepro.ii:33:7: required from here prepro.ii:33:7: internal compiler error: Segmentation fault } a = 0 ^ 0xab949f crash_signal ../../gcc/gcc/toplev.c:334 0x60f252 instantiate_template_1 ../../gcc/gcc/cp/pt.c:17269 0x60f252 instantiate_template(tree_node*, tree_node*, int) ../../gcc/gcc/cp/pt.c:17307 0x60ef6d instantiate_template_1 ../../gcc/gcc/cp/pt.c:17166 0x60ef6d instantiate_template(tree_node*, tree_node*, int) ../../gcc/gcc/cp/pt.c:17307 0x615c02 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool) ../../gcc/gcc/cp/pt.c:17666 0x5cc928 add_template_candidate_real ../../gcc/gcc/cp/call.c:3091 0x5cd0f3 add_template_candidate ../../gcc/gcc/cp/call.c:3169 0x5cd0f3 add_candidates ../../gcc/gcc/cp/call.c:5341 0x5cd6c1 build_new_method_call_1 ../../gcc/gcc/cp/call.c:8270 0x5cd6c1 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8466 0x5c738a build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int) ../../gcc/gcc/cp/call.c:8003 0x5c85b4 build_temp ../../gcc/gcc/cp/call.c:6174 0x5c85b4 convert_like_real ../../gcc/gcc/cp/call.c:6578 0x5d1117 build_user_type_conversion(tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/call.c:3871 0x694ddd ocp_convert(tree_node*, tree_node*, int, int, int) ../../gcc/gcc/cp/cvt.c:879 0x69cd35 expand_default_init ../../gcc/gcc/cp/init.c:1688 0x69cd35 expand_aggr_init_1 ../../gcc/gcc/cp/init.c:1857 0x69cfc5 build_aggr_init(tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/init.c:1606 0x5d94ad build_aggr_init_full_exprs ../../gcc/gcc/cp/decl.c:5946
[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983 --- Comment #8 from lucdanton at free dot fr --- (In reply to Jason Merrill from comment #7) > (In reply to lucdanton from comment #6) > > I've independently run into this bug and applying this patch to HEAD doesn't > > help on my end, the same ICE happens (except it is now pointing to line > > 6660 of > > course). > > Good to know. Please attach a testcase? Compiled with: g++-trunk -std=c++11 main.cpp class A { public: A m_fn1(); A(A const &); int *L; int ref; }; struct B : A { using base_type = A; B(); }; B::B() : base_type((0, m_fn1())) {}
[Bug middle-end/68983] [6 Regression] ICE: in store_field, at expr.c:6659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #6 from lucdanton at free dot fr --- (In reply to Jason Merrill from comment #5) > Created attachment 37245 [details] > possible patch > > Would this be an appropriate fix? It seems that if the source is a ref we > won't copy anything onto the stack. I've independently run into this bug and applying this patch to HEAD doesn't help on my end, the same ICE happens (except it is now pointing to line 6660 of course).
[Bug c++/68942] New: overly strict use of deleted function before argument-dependent lookup (ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942 Bug ID: 68942 Summary: overly strict use of deleted function before argument-dependent lookup (ADL) Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Tested on 5.2.0, 5.2.1 and 6. I believe the testcase is incorrectly rejected. Clang accepts the program. Note that leaving void foo(int); undefined, rather than defined as deleted, lets GCC accept the program. $ g++-trunk -std=c++14 main.cpp main.cpp: In function 'void lookup(X)': main.cpp:5:3: error: use of deleted function 'void foo(int)' { foo(x); } ^~~ main.cpp:1:6: note: declared here void foo(int) = delete; ^~~ $ cat main.cpp void foo(int) = delete; template void lookup(X x) { foo(x); } namespace ns { struct dummy {}; int foo(dummy) { return 3; } } // ns int main() { lookup(ns::dummy {}); }
[Bug c++/68918] New: spurious "invalid use of incomplete type" in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68918 Bug ID: 68918 Summary: spurious "invalid use of incomplete type" in trailing return type Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Happens with GCC 5.2.1 and 6. $ g++-trunk -std=c++14 main.cpp main.cpp:20:37: error: invalid use of incomplete type 'const struct foo' auto e() const -> decltype( this->a() ) ^~ main.cpp:1:8: note: definition of 'struct foo' is not complete until the closing brace struct foo { ^~~ main.cpp:20:37: error: invalid use of incomplete type 'const struct foo' auto e() const -> decltype( this->a() ) ^~ main.cpp:1:8: note: definition of 'struct foo' is not complete until the closing brace struct foo { ^~~ -- Testcase -- struct foo { static void a() {} // fine auto b() const -> decltype( this->a() ) {} // also fine template auto c() -> decltype( this->a() ) {} // even more fine template auto d() const -> decltype( a() ) {} // error: invalid use of incomplete type 'const struct foo' template auto e() const -> decltype( this->a() ) {} }; int main() { }
[Bug c++/68812] New: [concepts] bogus mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68812 Bug ID: 68812 Summary: [concepts] bogus mismatched argument pack lengths Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Using 6.0.0 20151208. Compiling yields: $ g++-trunk -std=c++1z main.cpp main.cpp: In instantiation of 'struct foo': main.cpp:12:32: required from here main.cpp:7:5: error: mismatched argument pack lengths while expanding 'Foo' template concept bool Foo = true; template struct foo { template // error: mismatched argument pack lengths while expanding 'Foo' foo(U...) requires (Foo && ...) {} }; void bar(foo) {} int main() { }
[Bug c++/68782] New: [6 regression] bad reference member formed with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782 Bug ID: 68782 Summary: [6 regression] bad reference member formed with constexpr Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Using 6.0.0 20151208 the last two asserts fire, whereas they don't with GCC 5.2.1 (as expected). The issue seems constexpr related as not marking from_value and from_aggr constexpr makes it go away. Compiled using: g++-trunk -std=c++11 main.cpp -std=c++14 and -std=c++1z result in the same behaviour. #include struct holder { int& value; }; constexpr holder from_value(int& value) { return { value }; } struct aggr { int i; }; constexpr holder from_aggr(aggr& a) { return from_value(a.i); } int main() { aggr a { 42 }; // these don't fire assert( &from_value(a.i).value != nullptr ); assert( &a.i == &from_value(a.i).value ); // those do assert( &from_aggr(a).value != nullptr ); assert( &a.i == &from_aggr(a).value ); }
[Bug c++/68630] New: [concepts] internal compiler error: in add_expr, at tree.c:7828
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68630 Bug ID: 68630 Summary: [concepts] internal compiler error: in add_expr, at tree.c:7828 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 36877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36877&action=edit Reduced testcase Using 6.0.0 20151201 (experimental). The testcase was reduced mechanically, must be compiled with any level of optimization above -O0 e.g.: $ g++-trunk -std=c++1z -Og prepro.ii The stack trace produced is noticeably similar to the one for PR 68116, but not identical either: prepro.ii:59:22: internal compiler error: in add_expr, at tree.c:7828 &functor(l, &local::get)(), "", l.i, ""); ^ 0xcb5d5d inchash::add_expr(tree_node const*, inchash::hash&) ../../gcc/gcc/tree.c:7828 0xcb5894 inchash::add_expr(tree_node const*, inchash::hash&) ../../gcc/gcc/tree.c:7801 0x8cf1de iterative_hash_expr ../../gcc/gcc/tree.h:4737 0x8cf1de gimplify_hasher::hash(gimple_temp_hash_elt const*) ../../gcc/gcc/gimplify.c:11535 0x8cf1de hash_table::find_slot(gimple_temp_hash_elt* const&, insert_option) ../../gcc/gcc/hash-table.h:408 0x8cf1de lookup_tmp_var ../../gcc/gcc/gimplify.c:523 0x8cf1de internal_get_tmp_var ../../gcc/gcc/gimplify.c:558 0x8cabdc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10982 0x8d1e1a gimplify_modify_expr ../../gcc/gcc/gimplify.c:4687 0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10057 0x8cb379 gimplify_target_expr ../../gcc/gcc/gimplify.c:5525 0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10426 0x8cb685 gimplify_addr_expr ../../gcc/gcc/gimplify.c:5053 0x8cb685 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10103 0x8d05d8 gimplify_call_expr ../../gcc/gcc/gimplify.c:2506 0x8cb86d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10028 0x8d1e1a gimplify_modify_expr ../../gcc/gcc/gimplify.c:4687 0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10057 0x8cb379 gimplify_target_expr ../../gcc/gcc/gimplify.c:5525 0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10426
[Bug c++/68628] New: [concepts] ICE: segmentation fault in crash_signal, toplev.c:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628 Bug ID: 68628 Summary: [concepts] ICE: segmentation fault in crash_signal, toplev.c:334 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- The source program was mechanically reduced. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20151130 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat prepro.ii template struct is_convertible; auto functor = [] {}; void forward(); namespace internal { template Type constant; struct A { template static auto impl(); }; template struct B : A { template auto operator()(F, Args... args) requires is_convertible::value; }; } using internal::constant; namespace functors { using internal::B; } template auto invoke_as = constant>; template bool Invokable{invoke_as(forward)}; static_assert ( Invokable < decltype ( functor ), int > $ g++-trunk -std=c++1z prepro.ii prepro.ii: In instantiation of 'bool Invokable<, int>': prepro.ii:21:17: required from here prepro.ii:12:40: internal compiler error: Segmentation fault is_convertible::value; ^ 0xab2e5f crash_signal ../../gcc/gcc/toplev.c:334 0x5a61ee resolve_args ../../gcc/gcc/cp/call.c:3956 0x5b0eeb build_new_method_call_1 ../../gcc/gcc/cp/call.c:8161 0x5b0eeb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8445 0x692ee0 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2360 0x5e9117 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:16451 0x5e9ba8 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:13379 0x5f1d0a tsubst_template_args ../../gcc/gcc/cp/pt.c:11077 0x5f220f tsubst_aggr_type ../../gcc/gcc/cp/pt.c:11274 0x5ea0f3 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:12743 0x5e6774 tsubst_qualified_id ../../gcc/gcc/cp/pt.c:13573 0x5e7531 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:16028 0x5e2b07 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:15620 0x6ea5ba satisfy_predicate_constraint ../../gcc/gcc/cp/constraint.cc:1794 0x6ea5ba satisfy_constraint_1 ../../gcc/gcc/cp/constraint.cc:1998 0x6eaa86 satisfy_constraint ../../gcc/gcc/cp/constraint.cc:2049 0x6eab67 constraints_satisfied_p(tree_node*) ../../gcc/gcc/cp/constraint.cc:2156 0x5aff95 add_function_candidate ../../gcc/gcc/cp/call.c:1994 0x5b061c add_template_candidate_real ../../gcc/gcc/cp/call.c:3118 0x5b0a23 add_template_candidate ../../gcc/gcc/cp/call.c:3160 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/68530] New: [C++14] sorry, unimplemented: unexpected AST of kind loop_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68530 Bug ID: 68530 Summary: [C++14] sorry, unimplemented: unexpected AST of kind loop_expr Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Possibly related to PR c++/68206, which could also be exhibiting both this and a potentially unrelated ICE. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20151125 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp struct thing { void foo() {} }; template constexpr int count() { auto item = thing {}; for(; (item.foo(), false);); return 0; } int main() { static_assert( count() == 0, "" ); } $ g++-trunk -std=c++14 main.cpp main.cpp: In function 'int main()': main.cpp:15:5: error: non-constant condition for static assertion static_assert( count() == 0, "" ); ^ main.cpp:15:30: error: 'constexpr int count() [with = int]' called in a constant expression static_assert( count() == 0, "" ); ^ main.cpp:6:15: note: 'constexpr int count() [with = int]' is not usable as a constexpr function because: constexpr int count() ^ main.cpp:6:15: sorry, unimplemented: unexpected AST of kind loop_expr main.cpp:6: confused by earlier errors, bailing out
[Bug c++/68510] New: [concepts] ICE: in gimplify_var_or_parm_decl, at gimplify.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68510 Bug ID: 68510 Summary: [concepts] ICE: in gimplify_var_or_parm_decl, at gimplify.c:1827 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 36817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36817&action=edit Reduced testcase Using g++-trunk (GCC) 6.0.0 20151124 (experimental). The testcase was mechanically reduced. An older snapshot used to be able to compile the original unreduced program, according to the reflog: commit c66cf0b787e892170f4981e8473aab601610a630 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229691 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/68509] New: [6 regression][C++1z] ICE: in check_return_expr, at cp/typeck.c:8635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68509 Bug ID: 68509 Summary: [6 regression][C++1z] ICE: in check_return_expr, at cp/typeck.c:8635 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Testcase compiles fine in C++11 and C++14 modes, ICE is in C++1z mode only. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20151124 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp constexpr auto foo(int i) { if(i == 0) { return 0; } else { return 'a'; } } int main() { using X = decltype( foo(0) ); return X {}; } $ g++-trunk -std=c++1z main.cpp main.cpp: In function 'constexpr auto foo(int)': main.cpp:6:16: internal compiler error: in check_return_expr, at cp/typeck.c:8635 return 'a'; ^~~ 0x66f5b3 check_return_expr(tree_node*, bool*) ../../gcc/gcc/cp/typeck.c:8635 0x68fa5e finish_return_stmt(tree_node*) ../../gcc/gcc/cp/semantics.c:867 0x6584e8 cp_parser_jump_statement ../../gcc/gcc/cp/parser.c:11414 0x6584e8 cp_parser_statement ../../gcc/gcc/cp/parser.c:10035 0x658bac cp_parser_statement_seq_opt ../../gcc/gcc/cp/parser.c:10426 0x658ce6 cp_parser_compound_statement ../../gcc/gcc/cp/parser.c:10380 0x65fb0c cp_parser_implicitly_scoped_statement ../../gcc/gcc/cp/parser.c:11520 0x658a01 cp_parser_selection_statement ../../gcc/gcc/cp/parser.c:10555 0x658a01 cp_parser_statement ../../gcc/gcc/cp/parser.c:10010 0x658bac cp_parser_statement_seq_opt ../../gcc/gcc/cp/parser.c:10426 0x658ce6 cp_parser_compound_statement ../../gcc/gcc/cp/parser.c:10380 0x658e3b cp_parser_function_body ../../gcc/gcc/cp/parser.c:20192 0x658e3b cp_parser_ctor_initializer_opt_and_function_body ../../gcc/gcc/cp/parser.c:20228 0x6599e8 cp_parser_function_definition_after_declarator ../../gcc/gcc/cp/parser.c:24836 0x65a93f cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/gcc/cp/parser.c:24748 0x65a93f cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:17972 0x65ac3d cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:11980 0x65b0d3 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11854 0x662d35 cp_parser_declaration ../../gcc/gcc/cp/parser.c:11751 0x661328 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:11630 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/68437] New: [concepts] fold expression, pack expansion, and deduced constraint requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437 Bug ID: 68437 Summary: [concepts] fold expression, pack expansion, and deduced constraint requirement Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 36775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36775&action=edit Minimal testcase This is using g++-trunk (GCC) 6.0.0 20151103 (experimental). Attached testcase is as minimal as I could manage. If I change the fold expression in the requirement to a 'manual', compile-time fold (not included in the testcase for brevity) then the program compiles as expected--this is the workaround that I'm using in the meantime.
[Bug c++/68372] New: [concepts] invalid use of pack expansion expression in member function template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372 Bug ID: 68372 Summary: [concepts] invalid use of pack expansion expression in member function template declaration Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I can't really understand the error and I don't know the rules very well, but here goes. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20151103 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-trunk -std=c++1z main.cpp main.cpp: In substitution of 'template requires predicate( C...) void foo::bar(X ...) [with X = {}]': main.cpp:18:16: required from here main.cpp:11:10: error: invalid use of pack expansion expression void bar(X...) ^ $ cat main.cpp template concept bool C = true; // fine template void bar(X...) {} struct foo { // error: invalid use of pack expansion expression template void bar(X...) {} }; int main() { bar(); foo {}.bar(); }
[Bug c++/68288] botched floating-point UDL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288 --- Comment #2 from lucdanton at free dot fr --- (In reply to TC from comment #1) > This behavior looks correct to me. (Clang behaves identically.) > > 0e1_e+0 is a valid pp-number, so per max munch it must be parsed that way, > as a single preprocessing token; it then fails to convert to a valid literal > token. > > 0e1_a+0 isn't a valid pp-number (the only thing in the pp-number production > that can precede + in C++ is e/E), so it's parsed as three tokens, 0e1_a, +, > and 0. Ditto for 0e1_e*0. > > However, GCC is treating 0e1_p+0 as a single pp-number, and rejecting > > long double operator""_p(long double) { return {}; } > auto x = 0e1_p+0; > > which isn't correct in C++. I should clarify that I can't tell which way it's meant to be parsed. This PR is either a bug report, or a feature enhancement request because that diagnostic looks less-than-helpful to me. Hopefully we'll soon know which it is.
[Bug c++/68288] New: botched floating-point UDL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288 Bug ID: 68288 Summary: botched floating-point UDL Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- I'm seeing this behaviour with GCC 6, GCC 5.2.0 and GCC 4.9.2. $ g++-trunk --version g++-trunk (GCC) 6.0.0 20151103 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp long double operator""_a(long double) { return {}; } long double operator""_e(long double) { return {}; } int main() { // all fine void(0e1_a+0); void(0e1_e*0); void(0e1_e +0); // error: unable to find numeric literal operator 'operator""e+0' void(0e1_e+0); } $ g++-trunk -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:10:10: error: unable to find numeric literal operator 'operator""_e+0' void(0e1_e+0); ^ main.cpp:10:10: note: use -std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes
[Bug c++/66586] New: Template backtrace is truncated/absent after 'template argument deduction/substitution failed:'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66586 Bug ID: 66586 Summary: Template backtrace is truncated/absent after 'template argument deduction/substitution failed:' Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 35801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35801&action=edit Minimal testcase I've noticed that sometimes GCC presents e.g. > main.cpp:8:25: note: template argument deduction/substitution failed: but then entirely omits the template instantiation backtrace. I've had a hard time reproducing it so far but I finally found an example. Also happens with 4.9.2. Unrolling the result template alias by hand into the return type of foo produces the expected behaviour, with a backtrace pointing to the mistake. $ g++-trunk --version g++-trunk (GCC) 5.1.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp template struct trivial { using type = int; }; template using result = typename trivial::type; template constexpr result foo(Xs...) { return 0; } int main() { foo(0, 0); } $ g++-trunk -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:13:13: error: no matching function for call to 'foo(int, int)' foo(0, 0); ^ main.cpp:8:25: note: candidate: template constexpr result foo(Xs ...) constexpr result foo(Xs...) ^ main.cpp:8:25: note: template argument deduction/substitution failed: $ #prompt resumes here!
[Bug c++/66336] New: [C++14][Variable templates] Spurious "error: expansion pattern contains no argument packs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66336 Bug ID: 66336 Summary: [C++14][Variable templates] Spurious "error: expansion pattern contains no argument packs" Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 35651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35651&action=edit Minimal testcase $ g++-trunk --version g++-trunk (GCC) 5.1.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp template int i {}; template void f() { // error: expansion pattern 'i' contains no argument packs int is[] = { i... }; } int main() { f(); } $ g++-trunk -std=c++14 main.cpp main.cpp: In function 'void f()': main.cpp:8:23: error: expansion pattern 'i' contains no argument packs int is[] = { i... };
[Bug c++/65497] New: Call to member function template named the same as class template is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65497 Bug ID: 65497 Summary: Call to member function template named the same as class template is rejected Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 35076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35076&action=edit Minimal testcase $ g++-trunk --version g++-trunk (GCC) 5.0.0 20150319 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp template struct foo {}; template struct bar { template void foo() const {} }; template void qux(bar b) { b.template foo(); } int main() { bar b; qux(b); } $ g++-trunk -std=c++03 main.cpp main.cpp: In function 'void qux(bar)': main.cpp:10:5: error: invalid use of 'struct foo' { b.template foo(); } ^ - I would expect the code to compile as-is (in all C++03/11/1y/1z modes). In any case, Clang does accept it. At the very least the error message seems bogus.
[Bug c++/65340] New: [C++14]ICE in mark_used, at decl2.c:5040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65340 Bug ID: 65340 Summary: [C++14]ICE in mark_used, at decl2.c:5040 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34981&action=edit Reduced testcase This is an ICE on invalid code. $ g++-trunk --version g++-trunk (GCC) 5.0.0 20150307 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-trunk -std=c++14 main.cpp main.cpp:4:34: error: expected identifier before ',' token struct recurse { auto operator()(, ) } ^ main.cpp:4:36: error: expected identifier before ')' token struct recurse { auto operator()(, ) } ^ main.cpp:4:36: error: expected ';' at end of member declaration main.cpp:4:38: error: expected ';' after struct definition struct recurse { auto operator()(, ) } ^ main.cpp:6:37: error: found ':' in nested-name-specifier, expected '::' auto &recurse = constant < functors : recurse > ^ main.cpp:7:1: error: expected ',' or ';' before '}' token } ^ main.cpp:12:44: error: found ':' in nested-name-specifier, expected '::' : recurse(0, 0)); ^ main.cpp:13:1: error: expected ';' after struct definition } ^ main.cpp:15:38: error: found ':' in nested-name-specifier, expected '::' auto &traverse = constant < functors : traverse > ; ^ main.cpp: In substitution of 'template decltype (reflect::recurse(0, 0)) functors::traverse::operator()(Algo, Value) [with Algo = int; Value = int]': main.cpp:16:37: required from here main.cpp:12:53: error: use of 'auto reflect::functors::recurse::operator()(int, int)' before deduction of 'auto' : recurse(0, 0)); ^ ' Internal compiler error: Error reporting routines re-entered. 0x641409 mark_used(tree_node*, int) ../../gcc/gcc/cp/decl2.c:5040 0x5da949 build_over_call ../../gcc/gcc/cp/call.c:7489 0x5e3e69 build_op_call_1 ../../gcc/gcc/cp/call.c:4335 0x5e3e69 build_op_call(tree_node*, vec**, int) ../../gcc/gcc/cp/call.c:4358 0x6ad497 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2424 0x60ddf5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:15211 0x60ef45 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:12530 0x646f4c dump_template_bindings ../../gcc/gcc/cp/error.c:369 0x646f4c dump_substitution ../../gcc/gcc/cp/error.c:1448 0x648da6 decl_to_string ../../gcc/gcc/cp/error.c:2910 0x648da6 cp_printer ../../gcc/gcc/cp/error.c:3494 0x108eb6b pp_format(pretty_printer*, text_info*) ../../gcc/gcc/pretty-print.c:613 0x108c5f8 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/gcc/diagnostic.c:865 0x108d1c2 error(char const*, ...) ../../gcc/gcc/diagnostic.c:1137 0x641409 mark_used(tree_node*, int) ../../gcc/gcc/cp/decl2.c:5040 0x5da949 build_over_call ../../gcc/gcc/cp/call.c:7489 0x5e3e69 build_op_call_1 ../../gcc/gcc/cp/call.c:4335 0x5e3e69 build_op_call(tree_node*, vec**, int) ../../gcc/gcc/cp/call.c:4358 0x6ad497 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2424 0x66046a cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6375 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/65202] New: [5.0 regression]ICE segfault with constexpr/noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65202 Bug ID: 65202 Summary: [5.0 regression]ICE segfault with constexpr/noexcept Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34866&action=edit Reduced testcase Using: $ g++-trunk --version g++-trunk (GCC) 5.0.0 20150223 (experimental) -- I get the following trace: $ g++-trunk -std=c++1y main.cpp main.cpp: In instantiation of 'decltype (adl::adl_swap(l, r)) adl::swap(L&, R&) [with L = adl::ns::foo; R = adl::ns::foo; decltype (adl::adl_swap(l, r)) = void]': main.cpp:22:19: required from here main.cpp:12:54: in constexpr expansion of 'adl::adl_swap, adl::ns::foo, {}>((* & l), (* & r))' main.cpp:12:6: internal compiler error: Segmentation fault auto swap(L &l, R &r) noexcept(noexcept(adl::adl_swap(l, r))) ^ 0xa93f2f crash_signal ../../gcc/gcc/toplev.c:383 0x6f0cfa cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2943 0x6f138a cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3118 0x6f068b cxx_eval_call_expression ../../gcc/gcc/cp/constexpr.c:1392 0x6f0e44 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3022 0x6f3627 is_sub_constant_expr(tree_node*) ../../gcc/gcc/cp/constexpr.c:3604 0x69761d check_noexcept_r ../../gcc/gcc/cp/except.c:1178 0xc8c7c4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) ../../gcc/gcc/tree.c:11086 0xc8df58 walk_tree_without_duplicates_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) ../../gcc/gcc/tree.c:11416 0x69732f expr_noexcept_p(tree_node*, int) ../../gcc/gcc/cp/except.c:1255 0x697492 finish_noexcept_expr(tree_node*, int) ../../gcc/gcc/cp/except.c:1240 0x60c308 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:14895 0x625e9d maybe_instantiate_noexcept(tree_node*) ../../gcc/gcc/cp/pt.c:20012 0x64104f mark_used(tree_node*, int) ../../gcc/gcc/cp/decl2.c:4941 0x5da459 build_over_call ../../gcc/gcc/cp/call.c:7489 0x5e3261 build_new_function_call(tree_node*, vec**, bool, int) ../../gcc/gcc/cp/call.c:4104 0x6ac979 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2407 0x660689 cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6368 0x66274a cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7438 0x6632e8 cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8173 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. -- Instead, I would expect the compiler to complain due to e.g. the namespaces left unclosed. (The testcase has been mechanically reduced so is nonsensical.) This is what happens with 4.8 and 4.9.
[Bug c++/65195] New: [5.0][C++14]Variable template cannot be used as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65195 Bug ID: 65195 Summary: [5.0][C++14]Variable template cannot be used as a function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34858&action=edit Minimal testcase $ g++-trunk --version g++-trunk (GCC) 5.0.0 20150223 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat main.cpp template T constant {}; template struct foo { int operator()() const { return 3; } }; template auto& f = constant>; int main() { // fine auto& ref = f; ref(); // error: f cannot be used as a function f(); } $ g++-trunk -std=c++14 main.cpp main.cpp: In function 'int main()': main.cpp:19:12: error: 'f' cannot be used as a function f();
[Bug c++/64352] New: [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 Bug ID: 64352 Summary: [5.0 regression] No SFINAE with deleted function Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34300&action=edit Minimal testcase Using: g++-trunk (GCC) 5.0.0 20141218 (experimental) Testcase: template struct bool_type { static constexpr bool value = B; }; using true_type = bool_type; using false_type = bool_type; template T&& declval(); template struct void_ { using type = void; }; template using void_t = typename void_::type; template struct _Has_addressof_free: false_type { }; template struct _Has_addressof_free <_Tp, void_t()) )>> : true_type { }; struct foo {}; void operator&(foo) = delete; int main() { static_assert( !_Has_addressof_free::value, "" ); // error: use of deleted function 'void operator&(foo)' static_assert( _Has_addressof_free::value, "" ); } This produces the following: $ g++-trunk -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:17:33: error: use of deleted function 'void operator&(foo)' <_Tp, void_t()) )>> ^ main.cpp:21:6: note: declared here void operator&(foo) = delete; ^ main.cpp:27:5: error: static assertion failed: static_assert( _Has_addressof_free::value, "" ); ^ I'm not entirely sure this is a regression, e.g. libstdc++'s testsuite/experimental/optional/observers/2.cc is very similar but passes. I'm working on experimental/optional however and I ended up tripping over this, and I didn't touch the _Has_addressof_* stuff. It is copied (almost) verbatim here, but not the declval/true_type/false_type/[__]void[_t] bits, in case that's of any help. Changing the deleted definition with e.g. a dummy definition ('{}') makes the program compiles as expected.
[Bug c++/64080] New: [5.0 regression][C++14]ICE in cxx_eval_store_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64080 Bug ID: 64080 Summary: [5.0 regression][C++14]ICE in cxx_eval_store_expression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34122&action=edit Program exhibiting ICE GCC version output: g++-trunk (GCC) 5.0.0 20141126 (experimental) The attached testcase is mechanically derived from a program that used to compile. Compilation command together with output: $ g++-trunk -std=c++14 ice.cpp ice.cpp: In instantiation of 'int invoke(Functor, Args&& ...) [with Functor = plus_assign; Args = {int, int}]': ice.cpp:18:37: required by substitution of 'template typename result::type ...>::type uncurry(Functor, Tuple, integer_sequence) [with Functor = plus_assign; Tuple = tuple; int ...Indices = {0, 0}; = ]' ice.cpp:27:41: required by substitution of 'template void zip_with(Functor, Tuples ...) [with int ...ElementIndices = 0; Functor = plus_assign; Tuples = {tuple}; = ]' ice.cpp:38:47: required from here ice.cpp:15:54: in constexpr expansion of 'functor.plus_assign::operator()((* & args#0), (* & args#1))' ice.cpp:14:5: internal compiler error: in cxx_eval_store_expression, at cp/constexpr.c:2492 int invoke(Functor functor, ^ 0x6d9fdd cxx_eval_store_expression ../../gcc/gcc/cp/constexpr.c:2492 0x6d7916 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2961 0x6d7653 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3192 0x6d795c cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3066 0x6d795c cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3066 0x6d7173 cxx_eval_call_expression ../../gcc/gcc/cp/constexpr.c:1335 0x6d8018 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2877 0x6d9857 is_sub_constant_expr(tree_node*) ../../gcc/gcc/cp/constexpr.c:3436 0x67e92d check_noexcept_r ../../gcc/gcc/cp/except.c:1168 0xc5b6e4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) ../../gcc/gcc/tree.c:11022 0xc5ce08 walk_tree_without_duplicates_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) ../../gcc/gcc/tree.c:11335 0x67e64f expr_noexcept_p(tree_node*, int) ../../gcc/gcc/cp/except.c:1245 0x67e7b2 finish_noexcept_expr(tree_node*, int) ../../gcc/gcc/cp/except.c:1230 0x5f7f48 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:14832 0x61154d maybe_instantiate_noexcept(tree_node*) ../../gcc/gcc/cp/pt.c:19899 0x62c01f mark_used(tree_node*, int) ../../gcc/gcc/cp/decl2.c:4879 0x5c6079 build_over_call ../../gcc/gcc/cp/call.c:7434 0x5cee51 build_new_function_call(tree_node*, vec**, bool, int) ../../gcc/gcc/cp/call.c:4081 0x693cf9 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2392 0x5f9595 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:15148 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/63522] New: [4.8/4.9/5.0] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522 Bug ID: 63522 Summary: [4.8/4.9/5.0] ICE: unexpected expression 'ElementIndices' of kind template_parm_index Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 33696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33696&action=edit Minimal testcase Attempting to compile the minimal testcase produces "internal compiler error: unexpected expression 'ElementIndices' of kind template_parm_index". I have tried the following versions: $ g++-trunk --version g++-trunk (GCC) 5.0.0 20141009 (experimental) $ g++ --version g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 $ g++-4.9 g++-4.9 (GCC) 4.9.0 Program fragment: template struct tuple; template void slice(); template using slice_result = decltype(slice); template , slice_result...>::type> void zip_with(Tuple...); decltype(zip_with(0)) Here is the full invocation and error using the snapshot of trunk: $ g++-trunk -std=c++11 main.cpp main.cpp: In substitution of 'template using slice_result = decltype (slice) [with int Index = ElementIndices; = {}]': main.cpp:5:11: required by substitution of 'template void zip_with(Tuple, ...) [with Tuple = int; Tuples = {}; int ...ElementIndices = {}; = ]' main.cpp:9:20: required from here main.cpp:5:11: internal compiler error: unexpected expression 'ElementIndices' of kind template_parm_index typename = ^ 0x6755a7 cxx_eval_constant_expression ../../gcc/gcc/cp/semantics.c:10050 0x676de6 cxx_eval_outermost_constant_expr ../../gcc/gcc/cp/semantics.c:10070 0x5dd190 convert_nontype_argument ../../gcc/gcc/cp/pt.c:5759 0x5dd190 convert_template_argument ../../gcc/gcc/cp/pt.c:6657 0x5deb5c coerce_template_parms ../../gcc/gcc/cp/pt.c:7081 0x5daa28 coerce_innermost_template_parms ../../gcc/gcc/cp/pt.c:7165 0x5daa28 instantiate_alias_template ../../gcc/gcc/cp/pt.c:15909 0x5daa28 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11723 0x5de392 tsubst_template_args ../../gcc/gcc/cp/pt.c:10123 0x5de58f tsubst_template_args ../../gcc/gcc/cp/pt.c:10105 0x5e09d0 tsubst_aggr_type ../../gcc/gcc/cp/pt.c:10320 0x5da0cf tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:12299 0x5e4125 type_unification_real ../../gcc/gcc/cp/pt.c:16841 0x5e741f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool) ../../gcc/gcc/cp/pt.c:16177 0x5a5ca8 add_template_candidate_real ../../gcc/gcc/cp/call.c:3025 0x5a6371 add_template_candidate ../../gcc/gcc/cp/call.c:3122 0x5a6371 add_candidates ../../gcc/gcc/cp/call.c:5253 0x5a797d perform_overload_resolution ../../gcc/gcc/cp/call.c:3971 0x5a93ea build_new_function_call(tree_node*, vec**, bool, int) ../../gcc/gcc/cp/call.c:4048 0x66ce39 finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2368 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/62299] New: [4.9/5 regression] ICE with __attribute__((__weakref__(""))) and __thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62299 Bug ID: 62299 Summary: [4.9/5 regression] ICE with __attribute__((__weakref__(""))) and __thread Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr $ g++-trunk --version g++-trunk (GCC) 5.0.0 20140828 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat testcase.cpp static __typeof 0 __gthrw_pthread_once __attribute__((__weakref__(""))); template class keyword_tss_ptrnoncopyable { static __thread T *value_; }; $ g++-trunk testcase.cpp -c testcase.cpp:4:2: internal compiler error: Segmentation fault }; ^ 0xc11bff crash_signal ../../gcc/gcc/toplev.c:339 0x8a49f4 tree_check ../../gcc/gcc/tree.h:2962 0x8a49f4 symbol_table::decl_assembler_name_hash(tree_node const*) ../../gcc/gcc/symtab.c:69 0x8a4c73 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool) ../../gcc/gcc/symtab.c:181 0x8a4efc symbol_table::symtab_initialize_asm_name_hash() ../../gcc/gcc/symtab.c:263 0x8a6d6f symtab_node::get_for_asmname(tree_node const*) ../../gcc/gcc/symtab.c:947 0x8b2f38 handle_alias_pairs ../../gcc/gcc/cgraphunit.c: 0x8b7ddc symbol_table::finalize_compilation_unit() ../../gcc/gcc/cgraphunit.c:2264 0x69cde2 cp_write_global_declarations() ../../gcc/gcc/cp/decl2.c:4666 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. -- This testcase was mechanically derived from preprocessed source. As best as I can tell the original __gthrw_pthread_once comes from c++/5.0.0/x86_64-unknown-linux-gnu/bits/gthr-default.h., in case that matters. The testcase is accepted by GCC 4.8 and 4.9.
[Bug c++/62072] New: [4.9/4.10 regression] No SFINAE performed for function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62072 Bug ID: 62072 Summary: [4.9/4.10 regression] No SFINAE performed for function type Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr $ cat main.cpp template struct tuple_size {}; template struct tuple_size: tuple_size {}; template struct query { static constexpr bool value = false; }; template struct query::type> { static constexpr bool value = true; }; int main() { // fine static_assert( !query::value, "" ); static_assert( !query::value, "" ); // error: invalid use of incomplete type 'struct tuple_size' static_assert( !query::value, "" ); } $ g++-trunk --version g++-trunk (GCC) 4.10.0 20140809 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-trunk -std=c++11 main.cpp main.cpp: In instantiation of 'struct tuple_size': main.cpp:20:34: required from here main.cpp:2:29: error: invalid use of incomplete type 'struct tuple_size' template struct tuple_size: tuple_size {}; ^ main.cpp:2:29: note: declaration of 'struct tuple_size' -- The testcase compiles fine against GCC 4.8.2 and 4.9.0.
[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 --- Comment #5 from lucdanton at free dot fr --- (In reply to Martin Jambor from comment #2) > Well, this is ICE on code with undefined behavior. Function test > calls itself with a parameter which is a reference to an object of > type child2 and then static_casts it to a reference to child1. These > are non-PODs, neither of these types is an ancestor of the other and > thus the use of static_cast is not allowed by the C++ standard. > […] I must apologise for the peculiar testcase I produced. I normally try to write a sensible program or fragment, but in this case I couldn’t figure out where the problematic behaviour was. In the end I resigned myself to (almost mechanically) discard bits and bits of the original TU until I was left with those things that triggered the ICE and nothing else. (I can’t help but notice that if the testcase is made a complete program by e.g. adding an empty main then strictly speaking there is no UB as control flow never reaches the invalid cast — with the ICE still happening.) For the record, and as best as I can tell, the original code was carefully performing the downcasts inside a (type)case, with no overlap or fallthrough. And if I do apply the patch you supplied, GCC does compile the library without issue.
[Bug c++/60600] New: ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 Bug ID: 60600 Summary: ICE in ipa_get_indirect_edge_target_1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 32404 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32404&action=edit Testcase $ g++-trunk --version g++-trunk (GCC) 4.9.0 20140319 (experimental) $ cat main.cpp struct data { data(int); }; struct top { virtual int topf(); }; struct intermediate: top { int topf() /* override */ { return 0; } }; struct child1: top { void childf() { data d(topf()); } }; struct child2: intermediate {}; void test(top& t) { child1& c = static_cast(t); c.childf(); child2 d; test(d); } $ g++-trunk main.cpp -O3 main.cpp:28:1: internal compiler error: in ipa_get_indirect_edge_target_1, at ipa-cp.c:1645 } ^ 0x10ac52e ipa_get_indirect_edge_target_1 ../../gcc/gcc/ipa-cp.c:1644 0xa1570c estimate_edge_devirt_benefit ../../gcc/gcc/ipa-inline-analysis.c:2955 0xa1570c estimate_edge_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:2987 0xa1570c estimate_calls_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3040 0xa1602c estimate_node_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3127 0xa18016 estimate_ipcp_clone_size_and_time(cgraph_node*, vec, vec, vec, int*, int*, int*) ../../gcc/gcc/ipa-inline-analysis.c:3163 0x10b17fc estimate_local_effects ../../gcc/gcc/ipa-cp.c:2004 0x10b17fc propagate_constants_topo ../../gcc/gcc/ipa-cp.c:2229 0x10b17fc ipcp_propagate_stage ../../gcc/gcc/ipa-cp.c:2329 0x10b17fc ipcp_driver ../../gcc/gcc/ipa-cp.c:3707 0x10b17fc execute ../../gcc/gcc/ipa-cp.c:3806 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. - This only happens with -O3, in all C++ modes. This may be a regression – the testcase was built from the preprocessed source of a third-party library, with stock settings. Presumably it built at some point before shipping.
[Bug c++/60314] New: [4.9][C++1y] ICE with decltype(auto) when generating debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60314 Bug ID: 60314 Summary: [4.9][C++1y] ICE with decltype(auto) when generating debug information Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Using trunk (g++-trunk (GCC) 4.9.0 20140222 (experimental)): $ cat main.cpp // fine // decltype(auto) qux() { return 42; } struct foo { // also ICEs if not static static decltype(auto) bar() { return 42; } }; int main() { } $ g++-trunk -std=c++1y main.cpp # Succeeds $ g++-trunk -std=c++1y main.cpp -g main.cpp:4:8: internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19864 struct foo { ^ 0x8dcdf9 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:19864 0x8d9945 gen_decl_die ../../gcc/gcc/dwarf2out.c:20361 0x8db9f4 gen_member_die ../../gcc/gcc/dwarf2out.c:19414 0x8db9f4 gen_struct_or_union_type_die ../../gcc/gcc/dwarf2out.c:19486 0x8db9f4 gen_tagged_type_die ../../gcc/gcc/dwarf2out.c:19676 0x8dcd6d gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:19823 0x8d9ba2 gen_decl_die ../../gcc/gcc/dwarf2out.c:20400 0xae80b2 rest_of_type_compilation(tree_node*, int) ../../gcc/gcc/passes.c:283 0x653f70 finish_struct_1(tree_node*) ../../gcc/gcc/cp/class.c:6636 0x65548c finish_struct(tree_node*, tree_node*) ../../gcc/gcc/cp/class.c:6801 0x6880a1 cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:19249 0x6880a1 cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:19468 0x6880a1 cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:14305 0x6a112d cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:11547 0x6a7ab9 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:11137 0x68b570 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11086 0x6b4abb cp_parser_declaration ../../gcc/gcc/cp/parser.c:10983 0x6b373d cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10869 0x6b4f9a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4014 0x6b4f9a c_parse_file() ../../gcc/gcc/cp/parser.c:31568 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/60095] New: Dubious diagnostics for attempted surrogate call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60095 Bug ID: 60095 Summary: Dubious diagnostics for attempted surrogate call function Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Using ‘gcc version 4.9.0 20140123 (experimental) (GCC)’ with the following snippet: // struct foo { typedef void(*ptr)(int&); operator ptr() const; }; int main() { foo f; void* p = 0; f(p); } // $ g++-trunk -std=c++03 main.cpp main.cpp: In function 'int main()': main.cpp:10:8: error: no match for call to '(foo) (void*&)' f(p); ^ main.cpp:1:8: note: candidate is: struct foo { ^ main.cpp:10:8: note: foo::ptr {aka void (*)(int&)} f(p); ^ main.cpp:10:8: note: candidate expects 2 arguments, 2 provided Same output for all -std=c++{03,11,1y} modes. If e.g. foo has a call operator instead, then the appropriate ‘no known conversion for argument 1 from 'void*' to 'int&'’ is produced.
[Bug c++/59329] Using `assert(...)` is not allowed in constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59329 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #2 from lucdanton at free dot fr --- As a workaround I thought about (ab)using the comma operator: return assert( cond ), expr; The reasoning being that C guarantees that assert(…) is a void expression (regardless of NDEBUG). This is rejected as well, although I’m not entirely sure why. After a quick look at the preprocessed source, it appears GCC rejects (‘body not a return statement’, again) functions of the form: //-- void some_extern_func(); constexpr int foo(int i) { return (true ? static_cast(0) : some_extern_func()), i; } //- If the third leg of the conditional operator is e.g. throw whatever (a common trick to ‘halt’ CTFE) everything behaves as expected. Does this warrant opening another bug?
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 --- Comment #1 from lucdanton at free dot fr --- Happens too with GCC 4.9 (20140105), as well as when using decltype(auto).
[Bug c++/58932] New: [4.9 Regression][C++11] Deleted functions and SFINAE in partial template specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58932 Bug ID: 58932 Summary: [4.9 Regression][C++11] Deleted functions and SFINAE in partial template specializations Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 31114 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31114&action=edit Testcase Using: $ gcc-snapshot --version gcc-snapshot (Debian 20131021-1) 4.9.0 20131021 (experimental) [trunk revision 203899] with flags -std=c++11 -Wall. The testcase is modified from PR 37208 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208). I'm fairly confident that previous 4.9 snapshots used to accept that kind of code (i.e. compile, undefined references notwithstanding), and I think 4.8 does -- no copy of 4.8.2 on hand though.
[Bug c++/58173] New: [C++11] Bad interaction between sizeof... and remainder (%) operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58173 Bug ID: 58173 Summary: [C++11] Bad interaction between sizeof... and remainder (%) operators Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr $ g++-snapshot --version g++-snapshot (GCC) 4.9.0 20130806 (experimental) $ cat main.cpp template struct foo { static constexpr auto N = sizeof...(T); struct bar { static_assert( N == 5, "" ); static_assert( (-1) % 5 == -1, "" ); static_assert( (-1) % N != -1, "" ); }; }; int main() { foo::bar(); } $ g++-snapshot -std=c++11 main.cpp --- That is, the compiler does not reject the program even though the three assertions cannot all hold simultaneously. As far as I can tell factoring the sizeof...(T) expression into N isn't necessary for the bug, and the use of the remainder operator is. This seems to happen with 4.8.1 as well.
[Bug c++/57644] New: [C++1y] Cannot bind bitfield to lvalue reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 Bug ID: 57644 Summary: [C++1y] Cannot bind bitfield to lvalue reference Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr $ g++-snapshot --version g++-snapshot (Debian 20130603-1) 4.9.0 20130603 (experimental) [trunk revision 199603] $ cat main.cpp struct foo { unsigned i: 32; }; int main() { foo f {}; return (f.i); } $ g++-snapshot -std=c++1y main.cpp main.cpp: In function 'int main()': main.cpp:8:15: error: cannot bind bitfield 'f.foo::i' to 'unsigned int&' return (f.i); ^ --- The code is accepted if either the parens are removed (i.e. just return f.i;) or when using -std=c++11.
[Bug c++/57401] New: 'Conflicting declaration' involving using declaration and dependent name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57401 Bug ID: 57401 Summary: 'Conflicting declaration' involving using declaration and dependent name Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Using 4.9.0 20130509 (experimental) [trunk revision 198734] with flags -std=c++11: $ cat main.cpp struct base { using base_type = base; using type = int; }; template struct derived: T { using typename derived::base_type::type; // Uses of once dependent type, explicitly introduced // into scope by using declaration above -- no complaints type foo(type); // No complaints as well static type t; }; // Error: conflicting declaration template typename derived::type derived::t = 0; int main() {} //--- $ g++-snapshot -std=c++11 main.cpp main.cpp:20:39: error: conflicting declaration 'typename derived::type derived::t' typename derived::type derived::t = 0; ^ main.cpp:15:17: error: 'derived::t' has a previous declaration as 'typename derived::base_type::type derived::t' static type t; ^ main.cpp:20:39: error: declaration of 'typename derived::base_type::type derived::t' outside of class is not definition [-fpermissive] typename derived::type derived::t = 0; ^ I suspect the code is wrongly rejected, as demonstrated by the other uses of type as if it weren't a dependent type anymore. (Admittedly writing a definition of foo that matches the declaration can be troublesome, but I assume this is the same issue in another form.) If it is any indication, Clang accepts the code.
[Bug libstdc++/57270] New: std::is_function ignores function ref-qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57270 Bug ID: 57270 Summary: std::is_function ignores function ref-qualifiers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Following the resolution of 57253 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57253) it seems worthwhile to point out that there are missing specializations of std::function such that e.g. static_assert( std::is_function(), "" ); is triggered.
[Bug c++/57254] New: Overload resolution failure when member function tempate is defined out-of-line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57254 Bug ID: 57254 Summary: Overload resolution failure when member function tempate is defined out-of-line Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Using 4.9.0 20130509 (experimental) [trunk revision 198734] and -std=c++11 the following is rejected: //--- struct foo { template void bar(T) &; template void bar(T) &&; }; template void foo::bar(T) & {} template void foo::bar(T) && {} int main() { foo f; // error: call of overloaded 'bar(int)' is ambiguous f.bar(0); } //--- Output is: main.cpp: In function 'int main()': main.cpp:19:12: error: call of overloaded 'bar(int)' is ambiguous f.bar(0); ^ main.cpp:19:12: note: candidates are: main.cpp:10:6: note: void foo::bar(T) [with T = int] void foo::bar(T) & {} ^ main.cpp:13:6: note: void foo::bar(T) [with T = int] void foo::bar(T) && {} ^ If on the other hand the members are defined inline, the code is accepted. Similarly if bar is made a set of non-template functions and e.g. T is an alias for int.
[Bug c++/57253] New: GCC ignores ref-qualifiers of pseudo-function types in explicit specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57253 Bug ID: 57253 Summary: GCC ignores ref-qualifiers of pseudo-function types in explicit specializations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr $ g++-snapshot --version g++-snapshot (Debian 20130509-1) 4.9.0 20130509 (experimental) [trunk revision 198734] $ cat main.cpp template struct foo; template<> struct foo {}; template<> struct foo {}; int main() {} $ g++-snapshot -std=c++11 main.cpp main.cpp:4:19: error: redefinition of 'struct foo' template<> struct foo {}; ^ main.cpp:3:19: error: previous definition of 'struct foo' template<> struct foo {}; ^ Aren't the specializations different, much like specializing on void() and void() const?
[Bug c++/57252] New: GCC does not treat ref-qualified overload set as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57252 Bug ID: 57252 Summary: GCC does not treat ref-qualified overload set as ambiguous Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 30099 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30099&action=edit Minimal testcase $ g++-snapshot --version g++-snapshot (Debian 20130509-1) 4.9.0 20130509 (experimental) [trunk revision 198734] $ cat main.cpp struct foo { void bar() & {} void bar() && {} }; int main() { // No complaints auto p = &foo::bar; // error: pointer-to-member-function type 'void (foo::*)() &' requires an lvalue (foo{}.*p)(); } $ g++-snapshot -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:11:13: error: pointer-to-member-function type 'void (foo::*)() &' requires an lvalue (foo{}.*p)(); ^ I would have thought &foo::bar would have been ambiguous outside of any context.
[Bug c++/57063] static_cast from data member to rvalue reference sometimes wrongfully produces lvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #5 from lucdanton at free dot fr 2013-04-28 02:56:42 UTC --- In case it might help: in the past I reported http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49447 where it was assignments which possibly had a wrong value category.
[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958 --- Comment #3 from lucdanton at free dot fr 2013-04-28 00:37:37 UTC --- I do make use of the variable in the pack; that the pack may be empty for some instantiations may or may not be something to look out for, but I don't think that it should be done by the unused variable warning. Perhaps I misunderstand the role of warning -- to me the 'used' in 'unused variable' means that it's conceptually used, not that it's e.g. ODR-used or any technical sense of the term. Should the following code warn? Who does that benefit? int spurious = 0 if(1) return 0; // never reached -- is spurious used or not? return spurious + 3; Since GCC doesn't warn for this I thought it shouldn't in the case of the pack expansion.
[Bug c++/56958] New: Spurious unused variable warning in empty pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958 Bug #: 56958 Summary: Spurious unused variable warning in empty pack expansion Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 29872 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29872 Minimal testcase Using: g++-snapshot (Debian 20130330-1) 4.9.0 20130330 (experimental) [trunk revision 197260] $ cat main.cpp template int foo(T... t) { int spurious = 0; return false ? foo(t + spurious...) : 0; } int main() { return foo(); } $ g++-snapshot -Wall -std=c++11 main.cpp main.cpp: In instantiation of 'int foo(T ...) [with T = {}]': main.cpp:10:16: required from here main.cpp:4:9: warning: variable 'spurious' set but not used [-Wunused-but-set-variable] int spurious = 0; ^ No such warning is produced when passing arguments to foo.
[Bug c++/56953] New: [4.9]Inheriting constructors triggers instantiation of parameters at point of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56953 Bug #: 56953 Summary: [4.9]Inheriting constructors triggers instantiation of parameters at point of declaration Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 29871 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29871 Testcase I am using: g++-snapshot (Debian 20130330-1) 4.9.0 20130330 (experimental) [trunk revision 197260] According to the diagnostic GCC gives, in some cases a using declaration that bring constructors into scope also triggers the instantiation of their parameters. The attachment is an example where a parameter takes the form `requires_complete`, where specializations of `requires_complete` are only valid when the template argument is complete. When inheriting a constructor taking such a parameter, GCC complains about an ill-formed specialization and points to the using declaration as having triggered the instantiation. This is regardless of the program using that constructor or not. I believe the equivalent program which doesn't use inheriting constructors is correct, as the instantiation takes place at the point of use and not the point of declaration, where the argument `completed_later` is completed. At the very least it is accepted by GCC (changing the define at the top of the file controls that). Do note that if `requires_complete` is itself left incomplete and not defined until later in the program, then GCC accepts the program. Presumably those parameters that are not themselves complete are not instantiated. The same happens using a snapshot of pre-release 4.8.
[Bug c++/56452] New: [C++11] Using declaration for inheriting constructors taints template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56452 Bug #: 56452 Summary: [C++11] Using declaration for inheriting constructors taints template parameter Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 29537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29537 Minimal reproducible testcase $ g++-snapshot --version g++-snapshot (Debian 20130222-1) 4.8.0 20130223 (experimental) [trunk revision 196236] $ cat main.cpp struct foo { explicit foo(int) {} }; template struct bar: T { using T::T; // Bad explicit bar(): T(0) {} void baz() { // Also bad using qux = T; } }; int main() {} $ g++-snapshot -std=c++11 -pthread main.cpp main.cpp: In constructor 'bar::bar()': main.cpp:10:21: error: 'using T::T' is not a non-static data member of 'bar' explicit bar(): T(0) {} ^ main.cpp: In member function 'void bar::baz()': main.cpp:15:21: error: expected type-specifier before 'T' using qux = T; ^ --- If the using declaration is commented out, then things proceed as usual. It is also possible to alias the template parameter before the using declaration (e.g. using base_type = T;) to substitute for uses of T after the declaration. Because this doesn't happen if bar is not a template, I don't think it is intended.
[Bug c++/56285] New: [C++11] Arguments to an inheriting constructor is not forwarded properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285 Bug #: 56285 Summary: [C++11] Arguments to an inheriting constructor is not forwarded properly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 29417 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29417 Minimal reproducible testcase $ g++-snapshot --version g++-snapshot (Debian 20130209-1) 4.8.0 20130209 (experimental) [trunk revision 195917] $ cat main.cpp struct foo { explicit foo(int&&) {} }; struct bar: private foo { using foo::foo; }; int main() { bar b { 42 }; } $ g++-snapshot -Wall -std=c++11 main.cpp main.cpp: In constructor 'bar::bar(int&&)': main.cpp:6:16: error: cannot bind 'int' lvalue to 'int&&' using foo::foo; ^ main.cpp:2:14: error: initializing argument 1 of 'foo::foo(int&&)' explicit foo(int&&) {} ^ main.cpp: In function 'int main()': main.cpp:11:16: note: synthesized method 'bar::bar(int&&)' first required here bar b { 42 };
[Bug c++/56065] New: Constant expression incorrectly recognized not as such
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56065 Bug #: 56065 Summary: Constant expression incorrectly recognized not as such Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr $ gcc-snapshot --version gcc-snapshot (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136] $ cat main.cpp #include template constexpr T id(T t) { return t; } template using Alias = std::integral_constant; template std::integral_constant f() { return {}; } template Alias g() { return {}; } int main() { // Fine constexpr auto I = id(5); (void)I; // Also fine f<0>(); // error: integral expression 'id(0)' is not constant g<0>(); }
[Bug libstdc++/55463] New: Result of std::mem_fn doesn't accept rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55463 Bug #: 55463 Summary: Result of std::mem_fn doesn't accept rvalues Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 28769 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28769 Reproducible testcase $ g++-snapshot --version g++-snapshot (Debian 20120915-1) 4.8.0 20120915 (experimental) [trunk revision 191353 The following program doesn't compile: #include #include // or can be std::unique_ptr as well template using Ptr = std::unique_ptr; struct foo { void bar() {} }; int main() { Ptr p { new foo }; // This is fine std::mem_fn(&foo::bar)(p); // This isn't std::mem_fn(&foo::bar)(std::move(p)); } As far as I can tell, that's because _Mem_fn<_Res (_Class::*)(_ArgTypes...)> has an operator() that only accepts _Tp& for smart pointers.
[Bug c++/55408] New: ICE for member template definition with non-type variadic parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55408 Bug #: 55408 Summary: ICE for member template definition with non-type variadic parameter Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 28740 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28740 Reproducible testcase $ g++-snapshot --version g++-snapshot (Debian 20120915-1) 4.8.0 20120915 (experimental) [trunk revision 191353] When attempting to compile this program: struct foo { template void bar(); }; template void foo::bar() {} int main() { extern int i; foo {}.bar<&i>(); } GCC complains: main.cpp: In function 'int main()': main.cpp:12:21: internal compiler error: Segmentation fault foo {}.bar<&i>(); ^ Some casual investigating suggests that this happens every time the definition for a member template is exactly the same as its declaration save for the fact that a non-type parameter is made variadic. Otherwise, e.g. if the parameter in question is a type or template parameter in the declaration or if the template is declared taking int and defined taking long... then GCC correctly reports that the definition doesn't have a match.
[Bug c++/54912] New: [C++11] Non-type argument to alias template is not a constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54912 Bug #: 54912 Summary: [C++11] Non-type argument to alias template is not a constant expression Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr gcc version 4.8.0 20121008 (experimental) with flags -Wall -pedantic -std=c++11 complains when fed the following program: template using Bool = int; template void foo() { using bar = Bool<(sizeof(T) >= 0)>; // line 7 } int main() { foo(); } Compiler output: main.cpp: In substitution of 'template using Bool = int [with bool B = (sizeof (T) >= 0)]': main.cpp:7:38: required from here main.cpp:7:38: error: integral expression '(sizeof (T) >= 0)' is not constant using bar = Bool<(sizeof(T) >= 0)>; ^ main.cpp:7:38: error: trying to instantiate 'template using Bool = int' Using the sizeof expression as the non-type parameter of a class template with the same template parameter list as the alias template is accepted. That same expression can also be used to initialize e.g. a constexpr bool variable, which will in fact in turn be accepted as a parameter to Bool. Previous snapshots of GCC used to accept this kind of code.
[Bug c++/52830] New: ICE: "canonical types differ for identity types ..." when attempting SFINAE with member type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Bug #: 52830 Summary: ICE: "canonical types differ for identity types ..." when attempting SFINAE with member type Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 27061 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27061 Testcase Using $ gcc-snapshot --version gcc-snapshot (Debian 20120313-1) 4.8.0 20120313 (experimental) [trunk revision 185345] I get the following when attempting to compile what I believe to be a correct testcase program (although I could be wrong on correctness): main.cpp:25:21: internal compiler error: canonical types differ for identical types std::enable_if::type, U>::value, int> and std::enable_if::value, int> The program compiles and behaves as expected if T is used instead of type/typename foo::type in both declaration and definition, or if bar is defined inline.
[Bug c++/41518] copy initialization of volatile objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518 lucdanton at free dot fr changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #3 from lucdanton at free dot fr 2012-02-15 15:08:11 UTC --- Reproducible with const: $ cat main.cpp struct copyable { copyable() {} copyable(copyable&) {} }; struct wrapper { copyable c; wrapper(int) {} }; int main() { wrapper const w = 0; } $ g++-snapshot -Wall -Wextra -pedantic main.cpp main.cpp: In function 'int main()': main.cpp:15:23: error: no matching function for call to 'wrapper::wrapper(const wrapper)' main.cpp:15:23: note: candidates are: main.cpp:9:5: note: wrapper::wrapper(int) main.cpp:9:5: note: no known conversion for argument 1 from 'const wrapper' to 'int' main.cpp:6:8: note: wrapper::wrapper(wrapper&) main.cpp:6:8: note: no known conversion for argument 1 from 'const wrapper' to 'wrapper&' $ g++-snapshot -Wall -Wextra -pedantic -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:15:23: error: no matching function for call to 'wrapper::wrapper(const wrapper)' main.cpp:15:23: note: candidates are: main.cpp:9:5: note: wrapper::wrapper(int) main.cpp:9:5: note: no known conversion for argument 1 from 'const wrapper' to 'int' main.cpp:6:8: note: wrapper::wrapper(wrapper&) main.cpp:6:8: note: no known conversion for argument 1 from 'const wrapper' to 'wrapper&' $ g++-snapshot -v ... gcc version 4.7.0 20120128 (experimental) [trunk revision 183664] (Debian 20120128-1) I noticed a similar problem when using copy-initialization on a const object of a class that is movable (with move constructor accepting T&&, not T const&&) but not copyable. I noticed that in C++11 8.5 Initializers [dcl.init] takes great care to specify: > [...] if the function is a constructor, the call initializes a temporary of > the cv-unqualified version of the destination type. on paragraph 16 (I'm using n3290). I'm not as familiar with C++03 but apparently the text only mentions creation of a temporary, without exactly specifying of which type.
[Bug c++/49447] New: operator= (and compound assignment ops) does not perfectly forward
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49447 Summary: operator= (and compound assignment ops) does not perfectly forward Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 24549 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24549 Minimal example An operator= (or compound assignment operator) that perfectly forwards its argument, like so: template T&& operator=(T&& t) { return std::forward(t); } does not behave exactly like a member will: template T&& member(T&& t) { return std::forward(t); } In particular, for some types (integral types it seems), when passed an lvalue reference to const, operator= returns an rvalue reference to const, e.g. long const& becomes long const&&. This does not happen for e.g. pointer types, class types or float or double; or when the function is instead declared as e.g. operator+ (but not operator+=) or as a regular member. This is using: gcc version 4.7.0 20110531 (experimental) [trunk revision 174470] (Debian 20110531-1) Attached is an example which fails to compile from trying to take the address of the result of operator= and from triggering a static_assert.