This affects g++ 8 and trunk (tested on r265559), but not 7.3.0. It first occurs in r249323. The corresponding patch (r249333) in the g++7 branch doesn't seem to cause problems there. This may be a duplicate of bug 87714. $ g++ -v -c equals3.cc Using built-in specs. COLLECT_GCC=/home/sage/ppl/bin4/bin/g++ Target: x86_64-pc-linux-gnu Configured with: /home/sage/gcc/configure --prefix=/home/sage/ppl/bin4 --enable-languages=c,c++ Thread model: posix gcc version 9.0.0 20181027 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/sage/ppl/bin4/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE equals3.cc -quiet -dumpbase equals3.c c -mtune=generic -march=x86-64 -auxbase equals3 -version -o /tmp/cc7QKAEq.s GNU C++14 (GCC) version 9.0.0 20181027 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.0 20181027 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0 /home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-pc-linux-gnu /home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward /home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include /usr/local/include /home/sage/ppl/bin4/include /home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++14 (GCC) version 9.0.0 20181027 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.0 20181027 (experimental), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7f3b9e82dac49b25cf1b2683fd4c3f1b equals3.cc: In instantiation of ‘d< <template-parameter-1-1> >::d(const d<e>&, a) [with e = c; <template-parameter-1-1> = int]’: equals3.cc:21:8: required from here equals3.cc:15:18: internal compiler error: in type_dependent_expression_p, at cp/pt.c:25230 15 | for (B g, h; g != h;) | ~~^~~~ 0x6446f6 type_dependent_expression_p(tree_node*) /home/sage/gcc/gcc/cp/pt.c:25230 0x6446f6 type_dependent_expression_p(tree_node*) /home/sage/gcc/gcc/cp/pt.c:25069 0x97c0fd uses_template_parms(tree_node*) /home/sage/gcc/gcc/cp/pt.c:10036 0x98453f tsubst_copy /home/sage/gcc/gcc/cp/pt.c:15438 0x99ea41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/sage/gcc/gcc/cp/pt.c:18907 0x99f1ae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/sage/gcc/gcc/cp/pt.c:18694 0x99f418 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/sage/gcc/gcc/cp/pt.c:18309 0x985007 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:17455 0x985807 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:16797 0x98506b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:16939 0x986ff5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:16636 0x98506b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:16939 0x9b2f97 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/sage/gcc/gcc/cp/pt.c:16621 0x9b2f97 instantiate_decl(tree_node*, bool, bool) /home/sage/gcc/gcc/cp/pt.c:24107 0x9b6d0b instantiate_pending_templates(int) /home/sage/gcc/gcc/cp/pt.c:24223 0x8db400 c_parse_final_cleanups() /home/sage/gcc/gcc/cp/decl2.c:4709 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ---------------------------------------- Minimal working example: equals3.cc: enum a { b }; class c; class B { public: bool operator!=(B); }; template <typename> class d { public: d(); template <typename e> d(const d<e> &, a = b); void f(d); }; template <> template <typename e> d<int>::d(const d<e> &, a); template <> template <typename e> d<int>::d(const d<e> &, a) { for (B g, h; g != h;) ; } void i() { d<int> j; d<c> k; j.f(k); }
Reduced: template <typename> struct d { template <typename e> d(e); }; template <> template <typename e> d<int>::d(e); template <> template <typename e> d<int>::d(e) { long g; (void)g; } template d<int>::d(char);
*** Bug 87714 has been marked as a duplicate of this bug. ***
Confirmed.
Created attachment 45448 [details] Candidate patch
(In reply to Alexandre Oliva from comment #4) > Created attachment 45448 [details] > Candidate patch I don't know enough about gcc to assess whether this is the "correct" solution, but I can confirm that this patch prevents the ICE both in trunk and in the gcc-8 branch. (It also fixes the ICE in the duplicate bug #87714.)
Author: aoliva Date: Tue Feb 5 06:11:25 2019 New Revision: 268529 URL: https://gcc.gnu.org/viewcvs?rev=268529&root=gcc&view=rev Log: [PR87770] test partial specializations for type dependence When instantiating a partial specialization of a template member function for a full specialization of a class template, we test whether the context of variables local to the partial specialization, i.e., the partial specialization itself, is dependent, and this ICEs in type_dependent_expression_p, when checking that the function type isn't type-dependent because it is not in a type-dependent scope. We shouldn't have got that far: the previous block in type_dependent_expression_p catches cases in which the function itself takes template arguments of its own, but it only did so for primary templates, not for partial specializations. This patch fixes that. for gcc/cp/ChangeLog PR c++/87770 * pt.c (instantiates_primary_template_p): New. (type_dependent_expression_p): Use it. for gcc/testsuite/ChangeLog PR c++/87770 * g++.dg/pr87770.C: New. Added: trunk/gcc/testsuite/g++.dg/pr87770.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
Thank you for fixing this. Would it be possible to backport this patch to the gcc-8 branch?
GCC 8.3 has been released.
*** Bug 89919 has been marked as a duplicate of this bug. ***
The releases/gcc-8 branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:d2221c1179354ad71c4944ea0cc634803aae98f1 commit r8-10066-gd2221c1179354ad71c4944ea0cc634803aae98f1 Author: Alexandre Oliva <aoliva@redhat.com> Date: Tue Feb 5 06:11:25 2019 +0000 c++: test partial specializations for type dependence [PR87770] When instantiating a partial specialization of a template member function for a full specialization of a class template, we test whether the context of variables local to the partial specialization, i.e., the partial specialization itself, is dependent, and this ICEs in type_dependent_expression_p, when checking that the function type isn't type-dependent because it is not in a type-dependent scope. We shouldn't have got that far: the previous block in type_dependent_expression_p catches cases in which the function itself takes template arguments of its own, but it only did so for primary templates, not for partial specializations. This patch fixes that. gcc/cp/ChangeLog 2019-02-05 Alexandre Oliva <aoliva@redhat.com> PR c++/87770 * pt.c (instantiates_primary_template_p): New. (type_dependent_expression_p): Use it. gcc/testsuite/ChangeLog 2019-02-05 Alexandre Oliva <aoliva@redhat.com> PR c++/87770 * g++.dg/pr87770.C: New.
Fixed for 8.4.