GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 19311 - [3.4/4.0 Regression] ICE in resolve_overloaded_unification
Summary: [3.4/4.0 Regression] ICE in resolve_overloaded_unification
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 3.4.4
Assignee: Kriang Lerdsuwanakij
URL:
Keywords: ice-on-valid-code, patch
: 20254 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-07 13:12 UTC by Jakub Jelinek
Modified: 2005-03-06 17:16 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.3.2
Known to fail: 3.4.0 4.0.0
Last reconfirmed: 2005-01-10 14:11:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2005-01-07 13:12:53 UTC
template <class R, class T>
struct A
{
  explicit A (R (T::*xf) ()) : M (xf) {}
  R operator () (T *x) const { return (x->*M) (); }
private:
  R (T::*M) ();
};

template <class R, class T, class C>
struct B
{
  explicit B (R (T::*xf) (C)) : M (xf) {}
  R operator () (T *x, C y) const { return (x->*M) (y); }
private:
  R (T::*M) (C);
};

template <class R, class T>
inline A<R, T>
foo (R (T::*x) ()) { return A<R, T> (x); }

template <class R, class T, class C>
inline B<R, T, C>
foo (R (T::*x) (C)) { return B<R, T, C> (x); }

template< int X = 1 >
struct I
{
  unsigned int i;
  I () : i (0) {}
  void o (unsigned int x) { i = x; }
  unsigned int o () const { return i; }
};

template<typename T>
struct S
{
  unsigned int bar (void)
  {
    I<> j;
    return foo <unsigned int, I<> > (&I<>::o) (&j);
  }
};

ICEs in GCC 3.4.x and HEAD, compiles with GCC 3.2.3.
Comment 1 Andrew Pinski 2005-01-07 13:45:56 UTC
Confirmed.
Comment 2 Wolfgang Bangerth 2005-01-07 20:58:06 UTC
This one is simpler: 
------------------------- 
template <class R, class T>          void foo (R (T::*x) ()); 
template <class R, class T, class C> void foo (R (T::*x) (C)); 
 
template<int> struct I { 
  int o (); 
  int o () const; 
}; 
 
template <int> void bar (void) { 
  foo <int, I<1> > (&I<1>::o); 
} 
------------------------------- 
 
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc 
x.cc: In function ?void bar()?: 
x.cc:10: internal compiler error: in resolve_overloaded_unification, at 
cp/pt.c:9523 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
 
W. 
Comment 3 Andrew Pinski 2005-01-08 22:52:22 UTC
: Search converges between 2004-07-18-trunk (#489) and 2004-07-19-trunk (#490).
: Search converges between 2004-07-28-3.4 (#35) and 2004-07-29-3.4 (#36).
Comment 4 Andrew Pinski 2005-01-10 00:50:24 UTC
I almost think this was caused by:
2004-07-18  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
2004-07-28  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
        
        PR c++/13092

Because that is when the date matches up for the regression hunter's dates on both the 3.4 branch and 
the mainline.
Comment 5 Kriang Lerdsuwanakij 2005-01-10 14:11:04 UTC
Will look at it.
Comment 6 Kriang Lerdsuwanakij 2005-01-12 10:49:42 UTC
Patch in progress.
Comment 7 Kriang Lerdsuwanakij 2005-01-13 06:06:59 UTC
Fixing it by queuing access checking until instantiation time 
turns out to be nasty:
- Need to invent new tree node, the current TREE_LIST cannot
  store the line number information.
- If only non-dependent qualified id are queued, need to check
  which one to queue.  If all are queued, then extra template 
  substitutions are needed which slow down the compiler.
I think the required changes is too big for 4.0 at this point.
Comment 8 Kriang Lerdsuwanakij 2005-01-17 14:37:17 UTC
Patch submitted that fixes the ICE:
  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01007.html

Queuing access checking until instantiation time will be addressed
in 4.1.  That issue has already been covered by PR16617 so this bug
can be closed once the ICE is fixed.
Comment 9 Giovanni Bajo 2005-01-17 15:25:36 UTC
(In reply to comment #7)
> Fixing it by queuing access checking until instantiation time 
> turns out to be nasty:
> - Need to invent new tree node, the current TREE_LIST cannot
>   store the line number information.

Why a new tree node? We are moving away from using trees also for container-
type data structures. You can write a normal structure with the node that must 
be access-checked and the line info, and put it into a Vec.
Comment 10 Kriang Lerdsuwanakij 2005-01-17 16:19:47 UTC
(In reply to comment #9)
> Why a new tree node? We are moving away from using trees also for container-
> type data structures. You can write a normal structure with the node that must 
> be access-checked and the line info, and put it into a Vec.

This is only a rough idea.  The actual implementation could be
different.
Comment 11 Caolan McNamara 2005-02-01 15:04:02 UTC
breaks current OOo2 build
Comment 12 Andrew Pinski 2005-03-01 00:09:39 UTC
*** Bug 20254 has been marked as a duplicate of this bug. ***
Comment 13 Giovanni Bajo 2005-03-02 00:05:59 UTC
Mark, what's the status on this? Kriang replied to your review with another 
patch, but nothing happened since. Can we have either patch approved?

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01007.html
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01332.html
Comment 14 Mark Mitchell 2005-03-04 02:16:46 UTC
The revised version is OK.
Comment 15 CVS Commits 2005-03-05 15:44:33 UTC
Subject: Bug 19311

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	lerdsuwa@gcc.gnu.org	2005-03-05 15:44:26

Modified files:
	gcc/cp         : init.c pt.c typeck.c ChangeLog 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: non-dependent11.C 

Log message:
	PR c++/19311
	* init.c (build_offset_ref): Don't build non-dependent SCOPE_REF.
	* pt.c (build_non_dependent_expr): Don't build NON_DEPENDENT_EXPR
	for OFFSET_TYPE.
	* typeck.c (build_x_unary_op): Don't build non-dependent SCOPE_REF.
	Also set PTRMEM_OK_P for NON_DEPENDENT_EXPR.
	(build_unary_op): Handle building ADDR_EXPR of OFFSET_REF inside
	template.
	
	* g++.dg/template/non-dependent11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.412&r2=1.413
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.978&r2=1.979
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.616&r2=1.617
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4652&r2=1.4653
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent11.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5112&r2=1.5113

Comment 16 Kriang Lerdsuwanakij 2005-03-05 15:46:40 UTC
Fixed in the mainline.  Other branches are being tested and will be
fixed once I finish retesting the patch.
Comment 17 CVS Commits 2005-03-06 16:59:27 UTC
Subject: Bug 19311

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	lerdsuwa@gcc.gnu.org	2005-03-06 16:59:19

Modified files:
	gcc/cp         : ChangeLog init.c pt.c typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: non-dependent11.C 

Log message:
	PR c++/19311
	* init.c (build_offset_ref): Don't build non-dependent SCOPE_REF.
	* pt.c (build_non_dependent_expr): Don't build NON_DEPENDENT_EXPR
	for OFFSET_TYPE.
	* typeck.c (build_x_unary_op): Don't build non-dependent SCOPE_REF.
	Also set PTRMEM_OK_P for NON_DEPENDENT_EXPR.
	(build_unary_op): Handle building ADDR_EXPR of OFFSET_REF inside
	template.
	
	* g++.dg/template/non-dependent11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.203&r2=1.3892.2.204
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.356.2.15&r2=1.356.2.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.51&r2=1.816.2.52
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.519.2.22&r2=1.519.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.368&r2=1.3389.2.369
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent11.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1

Comment 18 CVS Commits 2005-03-06 17:12:16 UTC
Subject: Bug 19311

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	lerdsuwa@gcc.gnu.org	2005-03-06 17:12:12

Modified files:
	gcc/cp         : ChangeLog init.c pt.c typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: non-dependent11.C 

Log message:
	PR c++/19311
	* init.c (build_offset_ref): Don't build non-dependent SCOPE_REF.
	* pt.c (build_non_dependent_expr): Don't build NON_DEPENDENT_EXPR
	for OFFSET_TYPE.
	* typeck.c (build_x_unary_op): Don't build non-dependent SCOPE_REF.
	Also set PTRMEM_OK_P for NON_DEPENDENT_EXPR.
	(build_unary_op): Handle building ADDR_EXPR of OFFSET_REF inside
	template.
	
	* g++.dg/template/non-dependent11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.3&r2=1.4648.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.412&r2=1.412.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978&r2=1.978.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.616&r2=1.616.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.19&r2=1.5084.2.20
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent11.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.4.1

Comment 19 Kriang Lerdsuwanakij 2005-03-06 17:16:02 UTC
Fixed in 3.4 and 4.0 branches.