From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 504 invoked by alias); 25 Oct 2002 13:31:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32462 invoked from network); 25 Oct 2002 13:30:57 -0000 Received: from unknown (HELO numa6.igpm.rwth-aachen.de) (134.130.161.59) by sources.redhat.com with SMTP; 25 Oct 2002 13:30:57 -0000 Received: from igpm.rwth-aachen.de (localhost [127.0.0.1]) by numa6.igpm.rwth-aachen.de (SGI-8.9.3/8.9.3) with ESMTP id QAA49203; Fri, 25 Oct 2002 16:21:35 +0200 (CST) Message-Id: <200210251421.QAA49203@numa6.igpm.rwth-aachen.de> Date: Fri, 25 Oct 2002 11:27:00 -0000 From: Reichelt Subject: Re: [Mainline regression] ICE when throwing strings To: mark@codesourcery.com, gcc@gcc.gnu.org In-Reply-To: <105750000.1035480906@warlock.codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg01522.txt.bz2 On 24 Oct, Mark Mitchell wrote: > > > --On Thursday, October 24, 2002 12:23:23 PM +0200 Reichelt > wrote: > >> Hi, >> >> we already have at least 4 PRs for this problem, so I just wanted to >> bring it to attention in order to prevent GNATS from getting flooded with >> more PRs of the same issue. >> >> Throwing an exception that uses strings will cause an ICE on >> mainline (just compile with g++ -O): >> >> ----------------------snip here-------------------- >> #include >> >> struct C >> { >> C (std::string) {} >> }; >> >> void foo () >> { >> throw C(std::string()); >> } >> ----------------------snip here-------------------- >> >> A reduced testcase can be found in PR 8186 and PR 7959. >> PR 8325 and PR 8244 are probably the same bug. > > I know exactly what is causing this; Jason wrote some code to elide > copy constructors in this situation and it doesn't play nice with > inlining. -fno-elide-constructors is a work-around. > > Jason knows about the bug and will fix it when he is no longer at the > C++ standards meeting. > > If you want, test replacing "flag_elide_constructors" with "false" in > stabilize_throw_expr; if that passes, you can go ahead and check it in > on the mainline. That should disable the new optimization and avoid the > bug. The good news is that -fno-elide-constructors makes things work for all four PRs. The bad news is that your proposed patch, which I implemented in the following way ---------------------------------------------------------------------- diff -up gcc/gcc/cp/except.c gcc-new/gcc/cp/except.c --- gcc/gcc/cp/except.c Fri Oct 25 10:16:49 2002 +++ gcc-new/gcc/cp/except.c Fri Oct 25 10:16:44 2002 @@ -587,6 +587,9 @@ stabilize_throw_expr (exp, initp) { tree init_expr; +#if 0 + /* Disabled, because we get ICEs when throwing strings (see PR 8186). */ + if (TREE_CODE (exp) == TARGET_EXPR && TREE_CODE (TARGET_EXPR_INITIAL (exp)) == AGGR_INIT_EXPR && flag_elide_constructors) @@ -610,6 +613,7 @@ stabilize_throw_expr (exp, initp) TREE_OPERAND (aggr_init, 1) = newargs; } else +#endif { exp = stabilize_expr (exp, &init_expr); } ---------------------------------------------------------------------- causes 3 regressions in the testsuite: FAIL: g++.eh/ctor1.C referenced below (test for errors, line 4) FAIL: g++.eh/ctor1.C can't copy (test for errors, line 12) FAIL: g++.eh/ctor1.C (test for excess errors) Should we prepare a patch to disable this optimization altogether or rather wait for Jasons return? Any thoughts? Greetings, Volker Reichelt