From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12993 invoked by alias); 26 Mar 2002 13:36:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12942 invoked by uid 71); 26 Mar 2002 13:36:02 -0000 Date: Tue, 26 Mar 2002 05:36:00 -0000 Message-ID: <20020326133602.12940.qmail@sources.redhat.com> To: dnovillo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Diego Novillo Subject: Re: c++/5504: Optimization breaks wei-ku-1 from blitz (fwd) Reply-To: Diego Novillo X-SW-Source: 2002-03/txt/msg00974.txt.bz2 List-Id: The following reply was made to PR c++/5504; it has been noted by GNATS. From: Diego Novillo To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/5504: Optimization breaks wei-ku-1 from blitz (fwd) Date: Tue, 26 Mar 2002 08:30:11 -0500 Jason, Although the PR indicates that g++ ICEs, the program actually compiles. However, it takes about 7 hours and cc1plus grows to ~650 Mb. The problem seems to be in the expansion of EH cleanups. I've been comparing gcc 3.0.4 with the 3.1 branch. This is what I found so far: - Both compilers seem to generate roughly the same number of trees. They both grow to about 47 Mb right before the call to expand_stmt() in semantics.c:expand_body(). - However, when expand_stmt() is called to expand the body of main(), the 3.1 compiler grows to 415Mb, while the 3.0.4. compiler grows to about 53 Mb. - The difference is in the calls to expand_eh_region_end_cleanup() The 3.0.4 compiler calls it 76 times. The 3.1 compiler calls it 59,212 times. Not surprisingly, we spend no more than a couple of minutes generating the initial RTL, and 7 hours trying to optimize it. We seem to be generating mostly fluff because the final .s file doesn't look overly large (a couple of Mb, IIRC). - The program seems to compile fine with -fno-exceptions. Jakub tracked the problem to your destructor cleanup patch from Dec01: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01532.html I don't know enough C++ to determine whether this is to be expected or not. The test case is rather large, so it may well be that 3.0.4 was not doing the right thing. Any ideas on what to try next? Thanks. Diego.