c++/1687: Extreme compile time regression from 2.95.2

c++/1687: Extreme compile time regression from 2.95.2

[Wolfgang Bangerth]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@apex68.ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/1687: Extreme compile time regression from 2.95.2
Date: Thu, 14 Nov 2002 14:35:15 -0600

 Re-confirmed with 3.3 CVS from 2002-11-10 and 3.2.1 pre from the same date.

Re: c++/1687: Extreme compile time regression from 2.95.2

[Steven Bosscher]

The following reply was made to PR c/1687; it has been noted by GNATS.

From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
	gcc-prs@gcc.gnu.org
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: 11 Apr 2003 23:37:47 +0200

 Op vr 11-04-2003, om 21:31 schreef Wolfgang Bangerth:
 > 
 > > Wolfgang, you were the last to re-confirm the PR, do you still
 > > see it?
 > 
 > I see long compile times for the C front-end, but it compiles 
 > instantaneously with the C++ front end. Don't know whether that's just a 
 > problem on my side or true -- can you check this (sorry, don't have time 
 > right now...).
 
 You are right. C++ takes a fraction of a second, C just dies.
 

Re: c++/1687: Extreme compile time regression from 2.95.2

[Wolfgang Bangerth]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, <kelley.cook@home.com>, <gcc-bugs@gcc.gnu.org>,
   <nobody@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Fri, 11 Apr 2003 14:31:05 -0500 (CDT)

 > Wolfgang, you were the last to re-confirm the PR, do you still
 > see it?
 
 I see long compile times for the C front-end, but it compiles 
 instantaneously with the C++ front end. Don't know whether that's just a 
 problem on my side or true -- can you check this (sorry, don't have time 
 right now...).
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Re: c++/1687: Extreme compile time regression from 2.95.2

[Steven Bosscher]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, kelley.cook@home.com,
	gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	bangerth <bangerth@ticam.utexas.edu>
Cc:  
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Fri, 11 Apr 2003 20:57:21 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=1687
 
 I cannot reproduce this with:
 - gcc-3.3 (GCC) 3.3 20030407 (prerelease) or
 - gcc-3.4 (GCC) 3.4 20030411 (experimental).
 
 Both give subsecond compile times.  Which is particularly nice
 because it means that we can say at least one positive thing about
 compile time performance of 3.3 (this is a regression that is not
 marked as one for some reason...).
 
 Wolfgang, you were the last to re-confirm the PR, do you still
 see it?
 
 Greetz
 Steven
 
 
 

Re: c++/1687: Extreme compile time regression from 2.95.2

[Zack Weinberg]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org, kelley.cook@home.com, gcc-bugs@gcc.gnu.org,
	pbienst@gcc.gnu.org, Zack Weinberg <zack@codesourcery.com>
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Sun, 10 Nov 2002 14:14:13 -0800

 On Sun, Nov 10, 2002 at 03:51:12PM -0600, Wolfgang Bangerth wrote:
 > 
 > Zack,
 > you had a patch for this problem, as mentioned in the audit. Do you know 
 > whether it was applied? I cannot find it in the ChangeLogs.
 
 Yes, the patch was applied.  It's in cp/ChangeLog:
 
 2001-04-24  Zack Weinberg  <zackw@stanford.edu>
 
         * cp/optimize.c: Include hashtab.h.
         (struct inline_data): Add tree_pruner.
         (expand_call_inline, expand_calls_inline): Use it when calling
         walk_tree.
         (optimize_function): Initialize and free tree_pruner.
 
 This code is now in tree-inline.c, by the way
 
 > However, at -O3 it still takes forever, now with both C and C++, which 
 > seems a further regression (since previously this held only for C++). I 
 > don't trust this for various reasons, so maybe someone can confirm this 
 > with -O3?
 
 C being slow is a consequence of its using the tree-based inliner
 (previously only C++ did).  I don't know why -O3 would cause further
 trouble.  You could build cc1plus profiled (make clean in both
 libiberty and gcc, make all in libiberty with CFLAGS="-g -O2 -profile",
 make cc1plus in gcc with CFLAGS="-g -O2 -profile"), run it on the test
 case, and take a look at the gprof output.
 
 zw

Re: c++/1687: Extreme compile time regression from 2.95.2

[Wolfgang Bangerth]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org, <kelley.cook@home.com>, <gcc-bugs@gcc.gnu.org>,
   <pbienst@gcc.gnu.org>, Zack Weinberg <zack@codesourcery.com>
Cc:  
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Sun, 10 Nov 2002 15:51:12 -0600 (CST)

 Zack,
 you had a patch for this problem, as mentioned in the audit. Do you know 
 whether it was applied? I cannot find it in the ChangeLogs.
 
 At any rate, I get reasonable compile times with -O2:
 tmp/g> time /home/bangerth/bin/gcc-3.3x-pre/bin/gcc -O2 -c x.cc
 real    0m0.168s
 user    0m0.150s
 sys     0m0.010s
 tmp/g> time /home/bangerth/bin/gcc-3.3x-pre/bin/gcc -O2 -c x.cc
 real    0m0.261s
 user    0m0.150s
 sys     0m0.000s
 
 However, at -O3 it still takes forever, now with both C and C++, which 
 seems a further regression (since previously this held only for C++). I 
 don't trust this for various reasons, so maybe someone can confirm this 
 with -O3?
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: c++/1687: Extreme compile time regression from 2.95.2

[Zack Weinberg]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Kelley Cook <kelley.cook@home.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Tue, 6 Feb 2001 12:43:21 -0800

 Following up to myself...
 
 I hacked up a walk_expr_tree.  It improves things by a bit: a 16-input
 mux() goes from 1min to 30sec on my machine (give or take).
 Unfortunately, the time taken is still O(3^N) in the number of
 inputs.  So that won't do.
 
 Using the 'visit each node only once' mechanism of walk_tree
 thoroughly squelches the performance problem.  (One can't use
 walk_tree_without_duplicates blindly - slightly more cleverness is
 required.  It's still simple.)  We get sub-second compile time all the
 way up to -O2 and 32 input mux().
 
 Before (17 inputs):
   8.29     91.80     7.62 215233608     0.00     0.00  expand_call_inline
 
 After (17 inputs):
   0.00      0.14     0.00      147     0.00     0.00  expand_call_inline
 
 After (32 inputs):
   0.00      0.15     0.00      269     0.00     0.00  expand_call_inline
 
 HOWEVER: I am not certain that the change is correct.  Suppose that a
 function A is a candidate for inlining, and it's called twice from the
 same function B.  If the two call_expr nodes are shared, we won't
 inline both calls.  There may be other problems as well.
 
 Patch follows.  Commentary from C++ team appreciated.  Will bootstrap
 and report.
 
 zw
 
 	* optimize.c: Include hashtab.h.
 	(struct inline_data): Add tree_pruner field.
 	(expand_call_inline, expand_calls_inline): Call walk_tree with
 	id->tree_pruner for fourth argument, putting it into
 	no-duplicates mode.
 	(optimize_function): Create and destroy a hash table for
 	duplicate pruning, store it in id.tree_pruner.
 
 ===================================================================
 Index: cp/optimize.c
 --- cp/optimize.c	2001/01/28 14:04:19	1.50
 +++ cp/optimize.c	2001/02/06 20:40:33
 @@ -28,6 +28,7 @@ Software Foundation, 59 Temple Place - S
  #include "input.h"
  #include "integrate.h"
  #include "varray.h"
 +#include "hashtab.h"
  
  /* To Do:
  
 @@ -62,6 +63,10 @@ typedef struct inline_data
    int in_target_cleanup_p;
    /* A stack of the TARGET_EXPRs that we are currently processing.  */
    varray_type target_exprs;
 +
 +  /* Hash table used to prevent walk_tree from visiting the same node
 +     umpteen million times.  */
 +  htab_t tree_pruner;
  } inline_data;
  
  /* Prototypes.  */
 @@ -655,7 +660,7 @@ expand_call_inline (tp, walk_subtrees, d
  	  if (i == 2)
  	    ++id->in_target_cleanup_p;
  	  walk_tree (&TREE_OPERAND (*tp, i), expand_call_inline, data,
 -		     NULL);
 +		     id->tree_pruner);
  	  if (i == 2)
  	    --id->in_target_cleanup_p;
  	}
 @@ -810,8 +815,12 @@ expand_calls_inline (tp, id)
       inline_data *id;
  {
    /* Search through *TP, replacing all calls to inline functions by
 -     appropriate equivalents.  */
 -  walk_tree (tp, expand_call_inline, id, NULL);
 +     appropriate equivalents.  Use walk_tree in no-duplicates mode
 +     to avoid exponential time complexity.  (We can't just use
 +     walk_tree_without_duplicates, because of the special TARGET_EXPR
 +     handling in expand_calls.  The hash table is set up in
 +     optimize_function.  */
 +  walk_tree (tp, expand_call_inline, id, id->tree_pruner);
  }
  
  /* Optimize the body of FN.  */
 @@ -863,11 +872,14 @@ optimize_function (fn)
  
        /* Replace all calls to inline functions with the bodies of those
  	 functions.  */
 +      id.tree_pruner = htab_create (37, htab_hash_pointer,
 +				    htab_eq_pointer, NULL);
        expand_calls_inline (&DECL_SAVED_TREE (fn), &id);
  
        /* Clean up.  */
        VARRAY_FREE (id.fns);
        VARRAY_FREE (id.target_exprs);
 +      htab_delete (id.tree_pruner);
      }
  
    /* Undo the call to ggc_push_context above.  */
>From gdr@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: gdr@gcc.gnu.org
To: gdr@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/1767
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010125123601.5206.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00710.html
Content-length: 795

The following reply was made to PR libstdc++/1767; it has been noted by GNATS.

From: gdr@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, gdr@gcc.gnu.org, m.duflot@ulg.ac.be,
  nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/1767
Date: 25 Jan 2001 12:26:31 -0000

 Synopsis: bug with std::deque<T>::const_iterator::operator->()
 
 Responsible-Changed-From-To: unassigned->gdr
 Responsible-Changed-By: gdr
 Responsible-Changed-When: Thu Jan 25 04:26:31 2001
 Responsible-Changed-Why:
     Analyzed
 State-Changed-From-To: open->closed
 State-Changed-By: gdr
 State-Changed-When: Thu Jan 25 04:26:31 2001
 State-Changed-Why:
     This bug is fixed in V3 (after the last merge from SGI-STL) so
     it is likely to be fixed in GCC-3.0
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1767&database=gcc
>From rodrigc@mediaone.net Sun Apr 01 00:00:00 2001
From: Craig Rodrigues <rodrigc@mediaone.net>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1709
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010210190600.10563.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01115.html
Content-length: 572

The following reply was made to PR c++/1709; it has been noted by GNATS.

From: Craig Rodrigues <rodrigc@mediaone.net>
To: rodrigc@mediaone.net, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1709
Date: Sat, 10 Feb 2001 14:00:04 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1709&database=gcc
 
 If I change the -O3 flag to -O2 the compiler crash goes away.
 There is a bug with -O3.
 
 I tested with this gcc version:
 gcc version 2.97 20010210 (experimental)
 
 --
 Craig Rodrigues
 http://www.gis.net/~craigr
 rodrigc@mediaone.net
 
 
 

Re: c++/1687: Extreme compile time regression from 2.95.2

[Zack Weinberg]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Scott A Crosby <crosby@qwes.math.cmu.edu>
Cc: Kelley Cook <kelley.cook@home.com>, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Wed, 14 Feb 2001 13:00:49 -0800

 On Wed, Feb 14, 2001 at 06:07:08AM -0500, Scott A Crosby wrote:
 > On Tue, 6 Feb 2001, Zack Weinberg wrote:
 > 
 > > Using the 'visit each node only once' mechanism of walk_tree
 > > thoroughly squelches the performance problem.  (One can't use
 > > walk_tree_without_duplicates blindly - slightly more cleverness is
 > > required.  It's still simple.)  We get sub-second compile time all the
 > > way up to -O2 and 32 input mux().
 > 
 > > HOWEVER: I am not certain that the change is correct.  Suppose that a
 > > function A is a candidate for inlining, and it's called twice from the
 > > same function B.  If the two call_expr nodes are shared, we won't
 > > inline both calls.  There may be other problems as well.
 > > 
 > > Patch follows.  Commentary from C++ team appreciated.  Will bootstrap
 > > and report.
 > 
 > 
 > Could you workaround this by walking the tree normally, and try to inline
 > at all of the nodes, but if you find out that you are scanning too many
 > nodes, you abort and use a workaround strategy, say, walk-each-node once?
 > 
 > Catch the pathalogical cases and shunt them elsewhere, and behave normally
 > otherwise?
 
 Let's find out if always walking each node once is safe, first.  It
 doesn't cause any C++ regressions, but I still don't know if it
 inhibits optimizations.  Paging C++ team...
 
 zw

Re: c++/1687: Extreme compile time regression from 2.95.2

[Zack Weinberg]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Kelley Cook <kelley.cook@home.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Wed, 7 Feb 2001 10:36:51 -0800

 On Tue, Feb 06, 2001 at 12:43:21PM -0800, Zack Weinberg wrote:
 > 
 > 	* optimize.c: Include hashtab.h.
 > 	(struct inline_data): Add tree_pruner field.
 > 	(expand_call_inline, expand_calls_inline): Call walk_tree with
 > 	id->tree_pruner for fourth argument, putting it into
 > 	no-duplicates mode.
 > 	(optimize_function): Create and destroy a hash table for
 > 	duplicate pruning, store it in id.tree_pruner.
 
 This survived an x86-linux bootstrap and reports the following test
 suite failures.  I do not know if they are regressions or not.
 
 FAIL: g++.dg/vtgc1.C scan-assembler (about 30 of these)
 FAIL: g++.ext/instantiate1.C not instantiated (test for errors, line 18)
 FAIL: g++.ext/instantiate1.C not instantiated (test for errors, line 20)
 FAIL: g++.jason/2371.C (test for excess errors)
 FAIL: g++.other/crash32.C (test for excess errors)
 FAIL: g++.other/loop2.C caused compiler crash
 
 zw
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/117
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010204113600.13429.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00914.html
Content-length: 627

The following reply was made to PR c++/117; it has been noted by GNATS.

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, jsjacob@eclipsenetworks.com,
  martin@loewis.home.cs.tu-berlin.de, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/117
Date: 4 Feb 2001 11:28:25 -0000

 Synopsis: Internal compiler error 19970302 on SCO_SV 3.2 2 i386
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Sun Feb  4 03:28:25 2001
 State-Changed-Why:
     The bug appears to be fixed in the CVS.  Tested with Jan 23, 2001 snapshot.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=117&database=gcc
>From aoliva@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: aoliva@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1882
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010311190601.3356.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02223.html
Content-length: 727

The following reply was made to PR c++/1882; it has been noted by GNATS.

From: aoliva@gcc.gnu.org
To: bumgard@roguewave.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1882
Date: 11 Mar 2001 19:01:18 -0000

 Synopsis: Compilation fails when a default constructor appears as the first argument in constructor template.
 
 State-Changed-From-To: open->closed
 State-Changed-By: aoliva
 State-Changed-When: Sun Mar 11 11:01:18 2001
 State-Changed-Why:
     This is the well-known parser error in G++, that can only be fixed with a parser rewrite.  I don't think it's worth keeping this bug report open; we all know about the problem.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1882&database=gcc

Re: c++/1687: Extreme compile time regression from 2.95.2

[Zack Weinberg]

The following reply was made to PR c++/1687; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@stanford.edu>
To: Kelley Cook <kelley.cook@home.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c++/1687: Extreme compile time regression from 2.95.2
Date: Tue, 6 Feb 2001 11:02:30 -0800

 On Tue, Feb 06, 2001 at 12:57:26PM -0500, Kelley Cook wrote:
 > I don't see a way to add onto the GNATs item I opened, so I shall just 
 > post it here and hope someone with access can add onto PR c++/1687
 
 You do it by cc:ing gcc-gnats and leaving the bug tag in the subject
 line.  Also note bug discussion belongs on gcc-bugs, not gcc-patches.
 
 > The geometric regression that occurs only happens when "-finline" is 
 > enabled (which happens with -O1)
 
 This is the same sort of problem as the last time you had trouble with
 this test case, but in a different place.  -O1 with a 16-input mux():
 
  68.47     40.14    40.14        54   743.33  1082.78  walk_tree
  16.09     49.57     9.43 236756969     0.00     0.00  expand_call_inline
   7.93     54.22     4.65 143489477     0.00     0.00  statement_code_p
   4.67     56.96     2.74 143489445     0.00     0.00  cp_statement_code_p
   2.58     58.47     1.51  71745291     0.00     0.00  first_rtl_op
 
 We've got the messy tree structure, with tons of pointers to the same
 few nodes, same as last time.  We're trying to walk over it, again,
 and visiting the same few nodes over and over, again.  It's just
 happening in a different place.  walk_tree(expand_call_inline) is
 responsible for finding call sites and expanding them inline, should
 this be feasible.  There are no call sites in your test function, but
 it doesn't know that and it's got to grovel through 236,756,969 tree
 nodes to find out.
 
 I am not sure what to do about this.  Unlike in RTL, there is no handy tag
 on the statement nodes to indicate "this one performs a function call."
 (Perhaps there should be.)  So using walk_stmt_tree is not practical.  Also
 there are strange things going on with TARGET_EXPRs which I do not
 understand.  We could go for walk_tree_without_duplicates, but not fully
 understanding the logic here I am not confident that would work. Maybe a
 walk_expr_tree that doesn't visit type and decl nodes would be enough of a
 performance improvement?
 
 zw
>From warp@iki.fi Sun Apr 01 00:00:00 2001
From: warp@iki.fi
To: gcc-gnats@gcc.gnu.org
Subject: c++/1585: An ICE caused by an illegal template definition
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010108161341.12157.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00097.html
Content-length: 1164

>Number:         1585
>Category:       c++
>Synopsis:       An ICE caused by an illegal template definition
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          ice-on-illegal-code
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 08 08:16:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Juha Nieminen
>Release:        gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
SunOS sarakerttunen 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-5_10
>Description:
g++ causes an internal compiler error with an illegal
template definition (specified below). The error is just
the regular one:

bug.cc:1: Internal compiler error.
bug.cc:1: Please submit a full bug report.
bug.cc:1: See <URL: http://www.gnu.org/software/gcc/faq.html#bugreport > for instructions.
>How-To-Repeat:
template<template<> class C>
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="bug.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bug.cc"

dGVtcGxhdGU8dGVtcGxhdGU8PiBjbGFzcyBDPgo=
>From gcc@treblig.org Sun Apr 01 00:00:00 2001
From: gcc@treblig.org
To: gcc-gnats@gcc.gnu.org
Subject: libstdc++/2255: libstdc++ incorrectly uses /lib/cpp to identify host compiler version
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010310221800.24469.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02166.html
Content-length: 1044

>Number:         2255
>Category:       libstdc++
>Synopsis:       libstdc++ incorrectly uses /lib/cpp to identify host compiler version
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 10 14:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Dr. David Alan Gilbert
>Release:        cvs as of 10/3/2001
>Organization:
>Environment:
Linux/Alpha, egcs-1.1.2 is system compiler, but path
set to pick up a recent (2.97+) gcc - verified with gcc -v and g++ -v
Cross building to 68k
>Description:
The libstdc++-v3 configure script uses cpp to determine the gcc
compiler version. (Circa line 2585 in current cvs).

For reasons I do not understand it appears to be picking up
the sytem C preprocessor in /lib/cpp

CXXCPP seems to get set to /lib/cpp

typescript of build available at: http://www.treblig.org/debug/typescript-m68k-cpp
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: