public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2003-04-11 19:06 Steven Bosscher
0 siblings, 0 replies; 10+ messages in thread
From: Steven Bosscher @ 2003-04-11 19:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2003-04-11 21:46 Steven Bosscher
0 siblings, 0 replies; 10+ messages in thread
From: Steven Bosscher @ 2003-04-11 21:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2003-04-11 19:36 Wolfgang Bangerth
0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Bangerth @ 2003-04-11 19:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* c++/1687: Extreme compile time regression from 2.95.2
@ 2002-11-20 18:58 Wolfgang Bangerth
0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Bangerth @ 2002-11-20 18:58 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2002-11-10 14:16 Zack Weinberg
0 siblings, 0 replies; 10+ messages in thread
From: Zack Weinberg @ 2002-11-10 14:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2002-11-10 13:56 Wolfgang Bangerth
0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Bangerth @ 2002-11-10 13:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2001-04-01 0:00 Zack Weinberg
0 siblings, 0 replies; 10+ messages in thread
From: Zack Weinberg @ 2001-04-01 0:00 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2001-04-01 0:00 Zack Weinberg
0 siblings, 0 replies; 10+ messages in thread
From: Zack Weinberg @ 2001-04-01 0:00 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2001-04-01 0:00 Zack Weinberg
0 siblings, 0 replies; 10+ messages in thread
From: Zack Weinberg @ 2001-04-01 0:00 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c++/1687: Extreme compile time regression from 2.95.2
@ 2001-04-01 0:00 Zack Weinberg
0 siblings, 0 replies; 10+ messages in thread
From: Zack Weinberg @ 2001-04-01 0:00 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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:
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-04-11 21:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-11 19:06 c++/1687: Extreme compile time regression from 2.95.2 Steven Bosscher
-- strict thread matches above, loose matches on Subject: below --
2003-04-11 21:46 Steven Bosscher
2003-04-11 19:36 Wolfgang Bangerth
2002-11-20 18:58 Wolfgang Bangerth
2002-11-10 14:16 Zack Weinberg
2002-11-10 13:56 Wolfgang Bangerth
2001-04-01 0:00 Zack Weinberg
2001-04-01 0:00 Zack Weinberg
2001-04-01 0:00 Zack Weinberg
2001-04-01 0:00 Zack Weinberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).