Bug 10661 - ICE in instantiate_decl, at cp/pt.c:10052 while instantiating static member variables
Summary: ICE in instantiate_decl, at cp/pt.c:10052 while instantiating static member v...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: 3.3.1
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2003-05-07 11:26 UTC by gawrilow
Modified: 2003-07-25 17:33 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
24-cell.cc.bz2 (290.41 KB, application/octet-stream)
2003-05-21 15:17 UTC, gawrilow
Details
reduced_1.ii.gz (168.15 KB, application/x-gzip )
2003-05-21 15:17 UTC, gawrilow
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gawrilow 2003-05-07 11:26:00 UTC
The software the attached program is part of (polymake) could not be compiled with any gcc 3.2.x, there were various ICEs (all submitted, and almost all reported as fixed on the main trunc only.)

This time the error occurs at a new place, but I'm not sure is it a new bug or simply a new symptom of an old desease. At any rate, it's once again a regression vs. gcc 3.1. Some lines in the attached source which seem incompatible with 3.1 are deliberately commented out in order to prove the regression directly.

BTW, it's somehow disappointing to see the regression cases remaining unfixed during years. Especially when our users upgrade to the newer gcc versions, fail to compile the downloaded software and then complain about it - right, to us. Although I realize that being in the role of a pure consumer I shouldn't criticize the developers too loudly...

Release:
gcc version 3.3 20030506 (prerelease)

Environment:
RedHat 7.3 on athlon PC
gcc configured with --enable-languages=c++ --enable-shared --with-cpu=athlon

How-To-Repeat:
Just unpack and compile the attached file.
Comment 1 Giovanni Bajo 2003-05-08 01:51:22 UTC
Responsible-Changed-From-To: unassigned->bajo
Responsible-Changed-Why: Analyzing this...
Comment 2 Wolfgang Bangerth 2003-05-08 09:51:27 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/10661
Date: Thu, 8 May 2003 09:51:27 -0500 (CDT)

 I forgot to say: for the slightly reduced testcase I attached, there are 
 several error messages before the ICE. They are unrelated, though, and 
 have crept up while I tried to delete random stuff. It's the ICE at the 
 end we are interested in. Since the ICE already existed in the original 
 code, it's also not an error recovery problem.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
Comment 3 Wolfgang Bangerth 2003-05-08 11:17:09 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: gawrilow@math.tu-berlin.de, <gcc-bugs@gcc.gnu.org>,
   <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/10661: [3.3/3.4? regression] ICE in instantiate_decl
Date: Thu, 8 May 2003 11:17:09 -0500 (CDT)

 > have such a larger and complex codebase,
 
 Ah, and I forgot to say that as well: I will refuse to look at any other 
 report that comes with 80k lines of templates. Please try to strip 
 things down, it's much easier for the author of the code than for us!
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Comment 4 Wolfgang Bangerth 2003-05-08 11:31:54 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: gawrilow@math.tu-berlin.de, <gcc-bugs@gcc.gnu.org>,
   <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/10661: [3.3/3.4? regression] ICE in instantiate_decl
Date: Thu, 8 May 2003 11:31:54 -0500 (CDT)

 > I have just finished a first small analysys. [...]
 > Your code is illegal: within iterator_chain<>::_init(), line 69731 is
                                                                ^^^^^
 > ill-formed:
 
 You're incredible, man!
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
 

Comment 5 Wolfgang Bangerth 2003-05-08 13:51:50 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Jason Merrill <jason@redhat.com>
Cc: Giovanni Bajo <giovannibajo@libero.it>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/10661
Date: Thu, 8 May 2003 13:51:50 -0500 (CDT)

 > Hmm, the analysis in the PR is correct; the testcase is ill-formed.  My
 > patch will make it work, but probably isn't worth applying; I don't think
 > well-formed code will have the same problem.
 
 I would appreciate some patch nevertheless: the testcase presently just 
 ICEs, without any prior error message. Whether you make the testcase 
 compile properly or reject it with an error, I don't care, but anything 
 should be better than just an ICE!
 
 Giovanni: you asked about tests with older compilers -- your testcase ICEs 
 every compiler from 2.95 to 3.3. It works with 3.4, i.e. we get a proper 
 error message. Fixing the issue with the missing "template" allows 
 compilers since 3.0 to succeed, 2.95 still ICEs.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Comment 6 Wolfgang Bangerth 2003-05-08 14:19:06 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Ewgenij,
    let me start out with two remarks:
    - your chances that someone takes care of this might be
      higher, if you don't start out whining about the state
      of 3.3 a few days before the release and then send us
      a bulk of 80,000 lines of template metaprogramming. This
      is the most tangled, complicated, unintelligible, evil
      code I have ever seen. I spent about 3 hours yesterday
      night reducing it to 46,000 lines, but it's very hard
      to reduce it and it would have been significantly easier
      had you sent in a _reduced_ testcase.
    
    - I managed to extract about a dozen other testcases that
      failed somewhere in the compiler while reducing the big
      chunk. I imagine, you must have seen things like that as
      well while developing. If you get something like that,
      please wend them in, preferrably, as said, as _small_
      code snippets.
    
      Since the code is so incredibly complex, it might be
      worthwhile to make it a testcase. So if you want and
      can, I think it would be appreciated if you would set
      up a system that updates gcc from CVS source every once
      in a while (day, week) and runs it against your code. 
      This way, you may be able to find bugs in gcc earlier
      than right before the release. The bug you reported will
      certainly not be fixed for 3.3.0.
    
    That being said:
    - the problem exists, it is an ICE in instantiate_decl.
    - it's a regression on 3.3. Code doesn't compile on 3.4,
      so I can't yet say what's on there
    - a somewhat smaller testcase is attached as reduced_1.ii
    - I will coordinate with Giovanni about how to further
      reduce the code. That's incredibly tedious business- on my way, I found a lot more ICEs. I'll reduce and submit
      them over time. If someone fixes the bug here and there
      are follow-up failures, please check for potentially
      submitted other bugs in this context
    
    W.
Comment 7 Giovanni Bajo 2003-05-08 15:16:12 UTC
State-Changed-From-To: analyzed->open
State-Changed-Why: it's not analyzed until we have a small testcase
Comment 8 Giovanni Bajo 2003-05-08 17:07:36 UTC
Responsible-Changed-From-To: bajo->unassigned
Responsible-Changed-Why: Analysys is done
Comment 9 Giovanni Bajo 2003-05-08 17:07:36 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Ok, I'm done with this report. This is the reduced
    snippet that triggers the bug:
    
    ------------------------------------------------
    template <class A>
    struct Foo
    {
    	static const int var = 0; 
    
    	template <class>
    	struct Nested
    	{
    		static const int nested_var = var;
    	}; 
    };
    
    template <class A>
    struct Bar
    {
        typename Foo<A>::Nested<void> a;
    };
    
    template struct Bar<void>;
    ------------------------------------------------
    pr10661.cpp: In instantiation of `const int Foo<void>::var':
    pr10661.cpp:9:   instantiated from `Foo<void>::Nested<void>'
    pr10661.cpp:16:   instantiated from `Bar<void>'
    pr10661.cpp:19:   instantiated from here
    pr10661.cpp:4: internal compiler error: in instantiate_decl, at cp/pt.c:10330
    Please submit a full bug report,
    
    As anticipated, the code is illegal: it's missing a
    keyword 'template' in line 16, but we should not ICE
    anyway. Now the funny thing is, this reduced snippet
    is not a regression. I have no _clue_ why the original
    big testcase did compile on 3.2, probably for some weird
    reason. And I will _not_ go through everything again to
    find the difference, since there is an easy fix for this:
    just make the code legal. 
    Anyway, while working on this I forked out about 10 other
    ICEs, which I will file to GNATS and analyze in the next
    few days.
Comment 10 Giovanni Bajo 2003-05-08 17:11:44 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: The code is crashing GCC since 2.95 at least, but it's fixed
    in 3.4. To make it work in 3.3, just fix the code to be
    legal as explained in the audit trail.
Comment 11 Giovanni Bajo 2003-05-08 18:13:28 UTC
From: "Giovanni Bajo" <giovannibajo@libero.it>
To: <bangerth@dealii.org>,
	<gawrilow@math.tu-berlin.de>,
	<gcc-bugs@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<giovannibajo@libero.it>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c++/10661: [3.3/3.4? regression] ICE in instantiate_decl
Date: Thu, 8 May 2003 18:13:28 +0200

 bangerth@dealii.org wrote:
 
 >     - it's a regression on 3.3. Code doesn't compile on 3.4,
 >       so I can't yet say what's on there
 
 Ewgenij, I suggest you to try compiling your library with GCC 3.4 as well,
 and submit testcases for it in case of failure. This is the right timeframe
 to do so if you want to be absolutely sure your software will run in 3.4.0
 as well. And as Wolfgang suggested, as a general rule of thumb, since you
 have such a larger and complex codebase, you might want to upgrade GCC from
 CVS every other week and check that everything always works.
 
 Giovanni Bajo
 

Comment 12 Giovanni Bajo 2003-05-08 18:28:57 UTC
From: "Giovanni Bajo" <giovannibajo@libero.it>
To: <bangerth@dealii.org>,
	<gawrilow@math.tu-berlin.de>,
	<gcc-bugs@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<giovannibajo@libero.it>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c++/10661: [3.3/3.4? regression] ICE in instantiate_decl
Date: Thu, 8 May 2003 18:28:57 +0200

 Hello Ewgenij,
 
 I have just finished a first small analysys.
 
 Your code is illegal: within iterator_chain<>::_init(), line 69731 is
 ill-formed:
 
       Functions::init::defs<0>::_do(*owner, *this);
 
 Functions::init::defs<0> is a dependent postfix-expression, so the code must
 be changed to:
 
       Functions::init::template defs<0>::_do(*owner, *this);
 
 With this change, your whole code can be compiled correctly. Thus, I change
 the class of this bug to "ice-on-illegal-code". Again, I suggest you to test
 this again with 3.4, which is much stricter wrt C++ standard conformance.
 
 I will now continue work to reduce the ICE.
 
 Giovanni Bajo
 
Comment 13 Jason Merrill 2003-05-15 22:26:34 UTC
From: jason@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/10661
Date: 15 May 2003 22:26:34 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_3-branch
 Changes by:	jason@gcc.gnu.org	2003-05-15 22:26:33
 
 Modified files:
 	gcc/cp         : call.c cp-tree.h pt.c ChangeLog 
 
 Log message:
 	PR c++/5388
 	* call.c (conditional_conversion): Don't consider implicit
 	conversions if T2 is a base of T1.
 	* cp-tree.h (DERIVED_FROM_P, UNIQUELY_DERIVED_FROM_P): Make boolean.
 	(ACCESSIBLY_UNIQUELY_DERIVED_P, PUBLICLY_UNIQUELY_DERIVED_P): Likewise.
 	
 	PR c++/10661
 	* pt.c (instantiate_class_template): Also instantiate our
 	enclosing class.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.341.2.19&r2=1.341.2.20
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.776.2.18&r2=1.776.2.19
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.635.2.22&r2=1.635.2.23
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.132&r2=1.3076.2.133