This came out of PR 14337: this legal piece of code ------------------ template <bool> struct Constraint { typedef int Result; }; template <typename T> struct IsInt; template <> struct IsInt<int> { static const bool value = true; }; template <typename T> typename Constraint<IsInt<T>::value>::Result foo(T); template <typename> void bar() { foo(1); } template void bar<int> (); --------------------- ICEs mainline and 3.4, but compiles fine with 3.3.4-pre: g/x> /home/bangerth/bin/gcc-3.3.4-pre/bin/c++ -c x.cc g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc x.cc: In function `void bar() [with <template-parameter-1-1> = int]': x.cc:14: instantiated from here x.cc:11: internal compiler error: in cxx_incomplete_type_diagnostic, at cp/ typeck2.c:273 Please submit a full bug report, I presume that the reason it actually gets to the place of the ICE is tied to the fact that it doesn't get the thing in PR 14337 right, but even then it shouldn't ICE. So there are two distinct problems, although one of the problem may be necessary to trigger the other. Giovanni, didn't you recently work on incomplete types? Maybe you have an idea in this field... W.
Confirmed. It is trying to say that "Constraint<IsInt<int>::value>" (the tree type is typename_type) is not a complete type, which is not true as reported in the other bug report.
The test case in this PR no longer causes the ICE (due to the fix for 14337), and I cannot concoct a variant that still triggers the ICE, so I'm marking this as fixed in GCC 3.4 and GCC 3.5.
Mark, I analyzed this. cxx_incomplete_type_diagnostic was ICEing because it was never supposed to get a typename_type (it must have resolved before). You fixed the real bug in PR14377. The only reason why I was keeping this around is to add some checking code to tsubst_build_and_copy (case CALL_EXPR) so that it would check valid incoming call expressions (to catch problems earlier). For instance, there is a piece of code there which seems cut & pasted from the parser, and you just modified it: if (koenig_p && (is_overloaded_fn (function) || DECL_P (function) || TREE_CODE (function) == IDENTIFIER_NODE)) function = perform_koenig_lookup (function, call_args); The problem is, I don't follow the code well enough to add checking to it. So, it doesn't really matter.
The obvious way to fix this, of course, is to go back, unapply the patch temporarily, observe that we get the ICE back, fix it, then reapply your patch to PR 14377. Whether that makes sense is another matter. If the fix for 14377 patched the only place where invalid data could be fed to cxx_incomplete_type_diagnostic, then it doesn't make much sense to fix the ICE here. If some other place could leak similarly wrong data down, then one should fix it. I personally have not much of an opinion. It's not terribly important, so waiting whether someone else can come up with a testcase using the compiler with the fix for 14377 is also an option. W.
Subject: Re: [3.4/3.5 Regression] ICE in cxx_incomplete_type_diagnostic bangerth at dealii dot org wrote: >Whether that makes sense is another matter. > Yes, exactly. I don't know whether it makes it sense or not, but we've got enough problems to fix without looking for more: let's just wait to see if someone retriggers this ICE in some other way.
Fair enough. Our users seem to be pretty good at exercising our product, so let's apply the Redmond method to this one :-) W.