[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( == );
}
int main()
{
// inlined decomp
{
aggr arg {};
auto& [val] = arg;
// fine
assert( == );
}
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] = [] {};
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)
}
[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<std::unique_ptr> 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<canary&&>(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<canary&&>(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=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*, va_gc,
vl_embed>**, 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()::<lambda(auto:1&)> [with auto:1 =
fix_type<main()::<lambda(auto:1&)> >]':
main.cpp:6:27: required from 'decltype(auto) fix_type::operator()()
[with Functor = main()::<lambda(auto:1&)>]'
main.cpp:25:17: required from here
main.cpp:21:17: error: use of 'decltype(auto) fix_type::operator()()
[with Functor = main()::<lambda(auto:1&)>]' 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()::<lambda(auto:1&)>]' 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<>, 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<std::_List_iterator<tree_node*>, 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*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8613
0x708de3 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, 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<model> bar() { return {}; }
};
int main()
{
container<model> {}.payload.bar();
}
$ g++-trunk -std=c++1z -fconcepts main.cpp
main.cpp: In instantiation of 'struct container<model >':
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*, va_gc,
vl_embed>**, 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<decltype( outer::outer_member() )> );
// 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=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<X, Y> variable templates and succeeds. The second command results in constraints that use the trait<X, Y>::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++/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++/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++/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=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*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8466
0x5c738a build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, 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<int, long int, double>':
main.cpp:12:32: required from here
main.cpp:7:5: error: mismatched argument pack lengths while expanding 'Foo<T,
U>'
template concept bool Foo = true;
template
struct foo {
template
// error: mismatched argument pack lengths while expanding 'Foo<T, U>'
foo(U...)
requires (Foo<T, U> && ...)
{}
};
void bar(foo<int, long, double>) {}
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( _value(a.i).value != nullptr );
assert( == _value(a.i).value );
// those do
assert( _aggr(a).value != nullptr );
assert( == _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=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 (l, ::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<gimplify_hasher, xcallocator>::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 <typename, typename> 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<Ret, decltype(impl(forward < Args(args)...))>::value;
};
}
using internal::constant;
namespace functors {
using internal::B;
}
template auto invoke_as = constant<functors::B>;
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<<lambda()>, int>':
prepro.ii:21:17: required from here
prepro.ii:12:40: internal compiler error: Segmentation fault
is_convertible<Ret, decltype(impl(forward < Args(args)...))>::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*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8445
0x692ee0 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, 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=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=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=35801action=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
templatetypename
struct trivial { using type = int; };
templatetypename... Xs
using result = typename trivialXs...::type;
templatetypename... Xs
constexpr resultXs... 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: templateclass ... Xs constexpr resultXs ...
foo(Xs ...)
constexpr resultXs... 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=35651action=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
templatetypename
int i {};
templatetypename... Xs
void f()
{
// error: expansion pattern 'iXs' contains no argument packs
int is[] = { iXs... };
}
int main()
{
fvoid, void, void();
}
$ g++-trunk -std=c++14 main.cpp
main.cpp: In function 'void f()':
main.cpp:8:23: error: expansion pattern 'iXs' contains no argument packs
int is[] = { iXs... };
[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=35076action=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
templatetypename struct foo {};
templatetypename
struct bar {
templatetypename void foo() const {}
};
templatetypename T
void qux(barT b)
{ b.template foovoid(); }
int main()
{
barvoid b;
qux(b);
}
$ g++-trunk -std=c++03 main.cpp
main.cpp: In function 'void qux(barT)':
main.cpp:10:5: error: invalid use of 'struct foovoid'
{ b.template foovoid(); }
^
-
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=34981action=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 'templateclass Algo, class Value 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*, vectree_node*, va_gc, vl_embed**, int)
../../gcc/gcc/cp/call.c:4358
0x6ad497 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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*, vectree_node*, va_gc, vl_embed**, int)
../../gcc/gcc/cp/call.c:4358
0x6ad497 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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=34866action=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::fooadl::ns::bar; R = adl::ns::fooadl::ns::bar; decltype
(adl::adl_swap(l, r)) = void]':
main.cpp:22:19: required from here
main.cpp:12:54: in constexpr expansion of
'adl::adl_swapadl::ns::fooadl::ns::bar, adl::ns::fooadl::ns::bar, {}((*
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_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../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_settree_node*,
default_hashset_traits*))
../../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*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4104
0x6ac979 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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=34858action=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
templatetypename T
T constant {};
templatetypename T
struct foo {
int operator()() const
{ return 3; }
};
templatetypename T
auto f = constantfooT;
int main()
{
// fine
auto ref = fint; ref();
// error: fint cannot be used as a function
fint();
}
$ g++-trunk -std=c++14 main.cpp
main.cpp: In function 'int main()':
main.cpp:19:12: error: 'fint' cannot be used as a function
fint();
[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=34300action=edit
Minimal testcase
Using:
g++-trunk (GCC) 5.0.0 20141218 (experimental)
Testcase:
templatebool B struct bool_type
{ static constexpr bool value = B; };
using true_type = bool_typetrue;
using false_type = bool_typefalse;
templatetypename T T declval();
templatetypename... struct void_ { using type = void; };
templatetypename... I using void_t = typename void_I...::type;
templatetypename _Tp, typename = void
struct _Has_addressof_free: false_type { };
templatetypename _Tp
struct _Has_addressof_free
_Tp, void_tdecltype( operator(declvalconst _Tp()) )
: true_type { };
struct foo {};
void operator(foo) = delete;
int main()
{
static_assert( !_Has_addressof_freeint::value, );
// error: use of deleted function 'void operator(foo)'
static_assert( _Has_addressof_freefoo::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_tdecltype( operator(declvalconst _Tp()) )
^
main.cpp:21:6: note: declared here
void operator(foo) = delete;
^
main.cpp:27:5: error: static assertion failed:
static_assert( _Has_addressof_freefoo::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=34122action=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 'templateclass Functor, class
Tuple, int ...Indices, class typename resulttypename tuple_elementIndices,
Tuple::type ...::type uncurry(Functor, Tuple, integer_sequenceint, Indices
...) [with Functor = plus_assign; Tuple = tupleint; int ...Indices = {0, 0};
template-parameter-1-4 = missing]'
ice.cpp:27:41: required by substitution of 'templateint ...ElementIndices,
class Functor, class ... Tuples, class void zip_with(Functor, Tuples ...)
[with int ...ElementIndices = 0; Functor = plus_assign; Tuples = {tupleint};
template-parameter-1-4 = missing]'
ice.cpp:38:47: required from here
ice.cpp:15:54: in constexpr expansion of
'functor.plus_assign::operator()int, int((* 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_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../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_settree_node*,
default_hashset_traits*))
../../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*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4081
0x693cf9 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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=33696action=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 typename... struct tuple;
template typename... void slice();
template int Index, typename... using slice_result = decltype(sliceIndex);
template typename Tuple, typename... Tuples, int... ElementIndices,
typename =
typename tupleslice_resultElementIndices, Tuples...,
slice_resultElementIndices, Tuples..::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 'templateint Index, class ... using slice_result
= decltype (sliceIndex) [with int Index = ElementIndices;
template-parameter-1-2 = {}]':
main.cpp:5:11: required by substitution of 'templateclass Tuple, class ...
Tuples, int ...ElementIndices, class void zip_with(Tuple, ...) [with Tuple =
int; Tuples = {}; int ...ElementIndices = {}; template-parameter-1-4 =
missing]'
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*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4048
0x66ce39 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, 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 typename T 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
templatetypename T struct tuple_size {};
templatetypename T struct tuple_sizeT const: tuple_sizeT {};
templatetypename T, typename = void
struct query {
static constexpr bool value = false;
};
templatetypename T
struct queryT, typename tuple_sizeT::type {
static constexpr bool value = true;
};
int main()
{
// fine
static_assert( !queryint::value, );
static_assert( !queryint const::value, );
// error: invalid use of incomplete type 'struct tuple_sizevoid()'
static_assert( !queryvoid()::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_sizevoid()':
main.cpp:20:34: required from here
main.cpp:2:29: error: invalid use of incomplete type 'struct
tuple_sizevoid()'
templatetypename T struct tuple_sizeT const: tuple_sizeT {};
^
main.cpp:2:29: note: declaration of 'struct tuple_sizevoid()'
--
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=32404action=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_castchild1(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*, vectree_node*,
va_heap, vl_ptr, vectree_node*, va_heap, vl_ptr, vecipa_agg_jump_function*,
va_heap, vl_ptr, 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)} conversion
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_castvoid(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=31114action=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
templatetypename... T
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()
{
fooint, int, int, int, int::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;
};
templatetypename T
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
templatetypename T
typename derivedT::type derivedT::t = 0;
int main()
{}
//---
$ g++-snapshot -std=c++11 main.cpp
main.cpp:20:39: error: conflicting declaration 'typename derivedT::type
derivedT::t'
typename derivedT::type derivedT::t = 0;
^
main.cpp:15:17: error: 'derivedT::t' has a previous declaration as 'typename
derivedT::base_type::type derivedT::t'
static type t;
^
main.cpp:20:39: error: declaration of 'typename derivedT::base_type::type
derivedT::t' outside of class is not definition [-fpermissive]
typename derivedT::type derivedT::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_functionvoid()(), ); is triggered.
[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=30099action=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++/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
templatetypename T struct foo;
template struct foovoid() {};
template struct foovoid() {};
int main()
{}
$ g++-snapshot -std=c++11 main.cpp
main.cpp:4:19: error: redefinition of 'struct foovoid()'
template struct foovoid() {};
^
main.cpp:3:19: error: previous definition of 'struct foovoid()'
template struct foovoid() {};
^
Aren't the specializations different, much like specializing on void() and
void() const?
[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 {
templatetypename T
void bar(T) ;
templatetypename T
void bar(T) ;
};
templatetypename T
void foo::bar(T) {}
templatetypename T
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++/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++/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++/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_completecompleted_later`, 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++/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
templatetypename... T
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++/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) {}
};
templatetypename T
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 'barT::bar()':
main.cpp:10:21: error: 'using T::T' is not a non-static data member of 'barT'
explicit bar(): T(0) {}
^
main.cpp: In member function 'void barT::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 type_traits
templatetypename T
constexpr T id(T t) { return t; }
templateint I
using Alias = std::integral_constantint, I;
templateint I
std::integral_constantint, id(I) f()
{ return {}; }
templateint I
Aliasid(I) g()
{ return {}; }
int main()
{
// Fine
constexpr auto I = id(5);
(void)I;
// Also fine
f0();
// error: integral expression 'idint(0)' is not constant
g0();
}
[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 functional
#include memory
// or can be std::unique_ptr as well
templatetypename T using Ptr = std::unique_ptrT;
struct foo { void bar() {} };
int main()
{
Ptrfoo 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 {
templateint*
void bar();
};
templateint*...
void foo::bar() {}
int main()
{
extern int i;
foo {}.bari();
}
GCC complains:
main.cpp: In function 'int main()':
main.cpp:12:21: internal compiler error: Segmentation fault
foo {}.bari();
^
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:
templatebool B
using Bool = int;
templatetypename T
void foo()
{
using bar = Bool(sizeof(T) = 0); // line 7
}
int main()
{
fooint();
}
Compiler output:
main.cpp: In substitution of 'templatebool B 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 'templatebool B 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_ifstd::is_sametypename fooT::type, U::value, int and std::enable_ifstd::is_sameT, U::value, int The program compiles and behaves as expected if T is used instead of type/typename fooT::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:
templatetypename T
T
operator=(T t)
{ return std::forwardT(t); }
does not behave exactly like a member will:
templatetypename T
T
member(T t)
{ return std::forwardT(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.
