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

["Zack Weinberg" <zackw@stanford.edu>]

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: