Summary: | [3.4 regression] ICE in lookup_member, at cp/search.c:1228 | ||
---|---|---|---|
Product: | gcc | Reporter: | Richard Biener <rguenth> |
Component: | c++ | Assignee: | Kriang Lerdsuwanakij <lerdsuwa> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | gcc-bugs, reichelt |
Priority: | P2 | Keywords: | ice-on-valid-code, monitored |
Version: | 3.4.0 | ||
Target Milestone: | 3.4.0 | ||
Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
Build: | i686-pc-linux-gnu | Known to work: | |
Known to fail: | Last reconfirmed: | 2003-11-06 13:56:58 | |
Bug Depends on: | |||
Bug Blocks: | 12944 |
Description
Richard Biener
2003-11-06 09:27:49 UTC
Confirmed. 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 |