From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zack Weinberg" To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c++/1687: Extreme compile time regression from 2.95.2 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010206190600.25946.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00999.html List-Id: The following reply was made to PR c++/1687; it has been noted by GNATS. From: "Zack Weinberg" To: Kelley Cook 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 for instructions. >How-To-Repeat: 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: