I get, with the testcase at http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/evaluatorTest3.ii.gz the following ICE: > g++ -c -ftemplate-depth-60 -fno-exceptions evaluatorTest3.cpp /net/bellatrix/home/rguenth/src/pooma-bib/r2/src/Evaluator/PatchFunction.h: In member function `void PatchEvaluator<MainEvaluatorTag>::evaluate(const A1&, const Function&) const [with ReadWriteTag = PatchTag1, A1 = Array<1, double, MultiPatch<UniformTag, Brick> >, Function = MyFunction]': /net/bellatrix/home/rguenth/src/pooma-bib/r2/src/Evaluator/PatchFunction.h:657: instantiated from `void PatchFunction<Function, ReadWriteTag>::operator()(const Array1&) const [with Array1 = Array<1, double, MultiPatch<UniformTag, Brick> >, Function = MyFunction, ReadWriteTag = PatchTag1]' /net/bellatrix/home/rguenth/src/pooma-bib/r2/src/Evaluator/tests/evaluatorTest3.cpp:170: instantiated from here /net/bellatrix/home/rguenth/src/pooma-bib/r2/src/Evaluator/PatchFunction.h:161: internal compiler error: in lookup_member, at cp/search.c:1228 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. This is with g++ (GCC) 3.4 20031105 (experimental) and is there at least since g++ (GCC) 3.4 20030908 (experimental). g++ 3.3.2 is fine with this testcase.
Confirmed.
Likely related to bug 10200.
Here's a short testcase that triggers the bug: ============================================= template<typename> struct A {}; template<> struct A<void> { template<typename T> void foo() { A<T> a; a.template foo<int>(); } }; void bar() { A<void> a; a.foo<int>(); } ============================================= With mainline I get: bug.ii: In member function `void A<void>::foo() [with T = int]': bug.ii:15: instantiated from here bug.ii:8: internal compiler error: in lookup_member, at cp/search.c:1228 With previous versions of gcc I get a decent error message. According to Phil's regression checker, the regression was introduced between 2003-07-08-trunk (#337) and 2003-07-09-trunk (#338). (Since PR 10200 appeared before that date, I doubt that these two are related.) Because this is invalid code I'm changing the keyword to ice-on-invalid-code. But the original example should be revisited when the small testcase is fixed.
Subject: Re: [3.4 regression] ICE in lookup_member, at cp/search.c:1228 On 6 Nov 2003, reichelt at gcc dot gnu dot org wrote: > With mainline I get: > > bug.ii: In member function `void A<void>::foo() [with T = int]': > bug.ii:15: instantiated from here > bug.ii:8: internal compiler error: in lookup_member, at cp/search.c:1228 > > With previous versions of gcc I get a decent error message. > > According to Phil's regression checker, the regression was introduced > between 2003-07-08-trunk (#337) and 2003-07-09-trunk (#338). > > (Since PR 10200 appeared before that date, I doubt that these two are related.) > > Because this is invalid code I'm changing the keyword to ice-on-invalid-code. > But the original example should be revisited when the small testcase is fixed. I believe the original testcase is valid code (intel icpc -ansi doesnt complain). But I'll recheck. Richard.
Ok. Here's a version with valid code: ============================================= template<typename> struct A { template<typename> void foo() {} }; template<> struct A<void> { template<typename T> void foo() { A<T> a; a.template foo<int>(); } }; void bar() { A<void> a; a.foo<int>(); } =============================================
Just one remark: The new parser never got this right, before the ICE it issued an error message: bug.cc: In member function `void A::foo() [with T = int]': bug.cc:18: instantiated from here bug.cc:11: error: invalid use of `A::foo()'
Subject: Re: [3.4 regression] ICE in lookup_member, at cp/search.c:1228 On Thu, 6 Nov 2003, reichelt at gcc dot gnu dot org wrote: > The new parser never got this right, before the ICE it issued an error > message: > > bug.cc: In member function `void A::foo() [with T = int]': > bug.cc:18: instantiated from here > bug.cc:11: error: invalid use of `A::foo()' gcc-3.3 got this right as long as I can remember - so I didn't notice this until early. Richard.
Will look at it.
Subject: Re: [3.4 regression] ICE in lookup_member, at cp/search.c:1228 On Mon, 17 Nov 2003, lerdsuwa at gcc dot gnu dot org wrote: > ------- Additional Comments From lerdsuwa at gcc dot gnu dot org 2003-11-17 14:31 ------- > Will look at it. Any progress? Its quite annoying... Thanks, Richard. -- Richard Guenther <richard dot guenther at uni-tuebingen dot de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Subject: Re: [3.4 regression] ICE in lookup_member, at cp/search.c:1228 rguenth at tat dot physik dot uni-tuebingen dot de wrote: >Any progress? Its quite annoying... > > A rewrite of some function to go with the new parser in 3.4 broke it. That part is tricky dealing with many many cases and misses one. I haven't spent time to figure out the right solution yet. --Kriang
Subject: Bug 12924 CVSROOT: /cvs/gcc Module name: gcc Changes by: lerdsuwa@gcc.gnu.org 2003-11-23 11:32:14 Modified files: gcc/cp : ChangeLog typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: template-id-2.C Log message: PR c++/12924 * typeck.c (finish_class_member_access_expr): Handle TEMPLATE_ID_EXPR with OVERLOAD and DECL nodes as the first operand. * g++.dg/template/template-id-2.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3772&r2=1.3773 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.511&r2=1.512 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3203&r2=1.3204 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/template-id-2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed in the mainline.
Kriang, what about adding my_friendly_assert (TREE_CODE (name) == IDENTIFIER_NODE)? It would help catching similar problems.
ok, forget it, it's already done in lookup_member :)
Subject: Re: [3.4 regression] ICE in lookup_member, at cp/search.c:1228 "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes: | Kriang, what about adding my_friendly_assert (TREE_CODE (name) == | IDENTIFIER_NODE)? It would help catching similar problems. I completely agree. It is a bit sad Kriang committed the patch so fast without letting us a chance to see whether that is what we think we want. I think, the documentation says somethere that the first operand is an IDENTIFIER_NODE. I think the patch and the oducmentation needs to be coherent. And I believe that Giovanni's suggestion should be realized in the patch. -- Gaby