Bug 28705 - [4.1 Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
Summary: [4.1 Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P1 normal
Target Milestone: 4.2.0
Assignee: Nathan Sidwell
URL:
Keywords: ice-on-invalid-code, ice-on-valid-code
: 28348 30425 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-12 21:55 UTC by Danny Smith
Modified: 2008-07-04 15:47 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.4.0 4.2.0 4.3.0
Known to fail: 4.1.0 3.4.5 4.1.3
Last reconfirmed: 2006-08-25 17:11:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Danny Smith 2006-08-12 21:55:20 UTC
As reported at:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1539256&group_id=2435

This testcase:
=====================================================================
namespace N
{
	struct s { };
	template<typename T> struct tplt { void mf(const T &) {} };
	tplt<s> &f();
}

template<typename T> bool g()
{
	N::s *p = 0;
	N::f().mf(s(p));
	return true;
}
====================================================================
ICES with

cfg.C: In function 'bool g()':
cfg.C:12: internal compiler error: in type_dependent_expression_p, at cp/pt.c:12837

This is with 
GNU C++ version 4.2.0 20060808 (experimental) (mingw32)

It also ICES with gcc-3.4.5

Danny
Comment 1 Andrew Pinski 2006-08-12 22:57:01 UTC
3.4.0 gave an error so this is a regression:
t.cc: In function `bool g()':
t.cc:11: error: no match for call to `(N::s) (N::s*&)'


I don't know if this is invalid code or not, but we should not be ICEing.
Comment 2 Wolfgang Bangerth 2006-08-13 00:26:36 UTC
The code is invalid (because there is no constructor s::s(s*)), but
we can make the code valid and still ICE:

--------------------------
namespace N
{
  struct A { A(A*); };
  void foo(const A &);
}

template<typename T> void g()
{
  N::A *p;
  N::foo(A(p));
}
-----------------

g/x> c++ -c x.cc
x.cc: In function 'void g()':
x.cc:10: internal compiler error: in type_dependent_expression_p, at cp/pt.c:12603
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.suse.de/feedback> for instructions.

The point of the exercise is that in the template, we have A(p); since
p is of type N::A*, we need to look up A in namespace A as well, so the
conversion constructor A(p) should be valid, should yield an object of
type N::A, which can be bound to the argument of N::foo.

W.
Comment 3 Nathan Sidwell 2006-09-01 18:10:25 UTC
2006-09-01  Nathan Sidwell  <nathan@codesourcery.com>

	PR c++/28705
	* semantics.c (finish_call_expr): Add assert.
	* name-lookup.c (lookup_arg_dependent): Check we found an overload
	or an object.
Comment 4 Nathan Sidwell 2006-09-01 18:10:25 UTC
Subject: Bug 28705

Author: nathan
Date: Fri Sep  1 18:10:17 2006
New Revision: 116638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116638
Log:
cp/
	PR c++/28705
	* semantics.c (finish_call_expr): Add assert.
	* name-lookup.c (lookup_arg_dependent): Check we found an overload
	or an object.
testsuite/
	PR c++/28705
	* g++.dg/lookup/koenig5.C: New.
	* g++.dg/template/crash56.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/lookup/koenig5.C
    trunk/gcc/testsuite/g++.dg/template/crash56.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 Andrew Pinski 2006-09-03 06:41:46 UTC
*** Bug 28348 has been marked as a duplicate of this bug. ***
Comment 6 Volker Reichelt 2007-02-09 01:30:08 UTC
This problem is a regression that is not fixed on the 4.1 branch yet.
Or is there a reason not to backport the fix?
Comment 7 Volker Reichelt 2007-02-09 01:31:04 UTC
*** Bug 30425 has been marked as a duplicate of this bug. ***
Comment 8 Martin Michlmayr 2007-04-28 11:44:32 UTC
Nathan, do you intend to backport this to 4.1?
Comment 9 Nathan Sidwell 2007-04-30 09:37:00 UTC
I hadn't planned on doing so, but I think such a backport is safe.
Comment 10 Joseph S. Myers 2008-07-04 15:47:41 UTC
Closing 4.1 branch.