Here after resolving the address of a template-id inside decltype, we end up instantiating the chosen specialization from the call to mark_used in resolve_nondeduced_context, even though only its type is needed.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look for trunk? gcc/cp/ChangeLog: PR c++/71879 * semantics.c (finish_decltype_type): Temporarily increment cp_unevaluated_operand during call to resolve_nondeduced_context. gcc/testsuite/ChangeLog: PR c++/71879 * g++.dg/cpp0x/decltype-71879.C: New test. --- gcc/cp/semantics.c | 2 ++ gcc/testsuite/g++.dg/cpp0x/decltype-71879.C | 5 +++++ 2 files changed, 7 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype-71879.C diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c index c8a6283b120..cad55665ce8 100644 --- a/gcc/cp/semantics.c +++ b/gcc/cp/semantics.c @@ -10098,7 +10098,9 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p, /* The type denoted by decltype(e) is defined as follows: */ + ++cp_unevaluated_operand; expr = resolve_nondeduced_context (expr, complain); + --cp_unevaluated_operand; if (invalid_nonstatic_memfn_p (input_location, expr, complain)) return error_mark_node; diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype-71879.C b/gcc/testsuite/g++.dg/cpp0x/decltype-71879.C new file mode 100644 index 00000000000..9da4d40ca70 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/decltype-71879.C @@ -0,0 +1,5 @@ +// PR c++/71879 +// { dg-do compile { target c++11 } } + +template <class T> void f(T x) { x.fail(); } +using R = decltype(&f<int>); -- 2.30.0.155.g66e871b664