Bug 12924 - [3.4 regression] ICE in lookup_member, at cp/search.c:1228
Summary: [3.4 regression] ICE in lookup_member, at cp/search.c:1228
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 critical
Target Milestone: 3.4.0
Assignee: Kriang Lerdsuwanakij
URL:
Keywords: ice-on-valid-code, monitored
Depends on:
Blocks: 12944
  Show dependency treegraph
 
Reported: 2003-11-06 09:27 UTC by Richard Biener
Modified: 2004-01-17 04:22 UTC (History)
2 users (show)

See Also:
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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2003-11-06 09:27:49 UTC
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.
Comment 1 Kriang Lerdsuwanakij 2003-11-06 13:56:57 UTC
Confirmed.
Comment 2 Andrew Pinski 2003-11-06 16:41:25 UTC
Likely related to bug 10200.
Comment 3 Volker Reichelt 2003-11-06 17:28:35 UTC
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.
Comment 4 Richard Biener 2003-11-06 17:31:25 UTC
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.

Comment 5 Volker Reichelt 2003-11-06 17:35:30 UTC
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>();
}
=============================================
Comment 6 Volker Reichelt 2003-11-06 17:43:45 UTC
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()'
Comment 7 Richard Biener 2003-11-06 18:14:07 UTC
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.
Comment 8 Kriang Lerdsuwanakij 2003-11-17 14:31:27 UTC
Will look at it.
Comment 9 Richard Biener 2003-11-21 12:48:33 UTC
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/
Comment 10 Kriang Lerdsuwanakij 2003-11-21 16:55:33 UTC
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



Comment 11 CVS Commits 2003-11-23 11:32:17 UTC
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

Comment 12 Kriang Lerdsuwanakij 2003-11-23 11:32:43 UTC
Fixed in the mainline.
Comment 13 Giovanni Bajo 2003-11-23 13:51:49 UTC
Kriang, what about adding my_friendly_assert (TREE_CODE (name) == 
IDENTIFIER_NODE)? It would help catching similar problems.
Comment 14 Giovanni Bajo 2003-11-23 13:54:15 UTC
ok, forget it, it's already done in lookup_member :)
Comment 15 Gabriel Dos Reis 2003-11-23 13:58:35 UTC
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