From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17790 invoked by alias); 15 Oct 2007 08:51:28 -0000 Received: (qmail 17782 invoked by uid 22791); 15 Oct 2007 08:51:27 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Oct 2007 08:51:25 +0000 Received: by py-out-1112.google.com with SMTP id a29so3543320pyi for ; Mon, 15 Oct 2007 01:51:23 -0700 (PDT) Received: by 10.65.121.9 with SMTP id y9mr11991770qbm.1192438282881; Mon, 15 Oct 2007 01:51:22 -0700 (PDT) Received: by 10.65.203.7 with HTTP; Mon, 15 Oct 2007 01:51:22 -0700 (PDT) Message-ID: <84fc9c000710150151s3970c025r9e2cc1a1ae50b67a@mail.gmail.com> Date: Mon, 15 Oct 2007 09:05:00 -0000 From: "Richard Guenther" To: "Alexandre Oliva" Subject: Re: [vtab (and trunk?)] fix fallout from SSA-coalescing user variables Cc: gcc-patches@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84fc9c000710020219w4128a866xe8f36fe7fd464bb0@mail.gmail.com> <84fc9c000710031122r70c6395crf8cb6ed4d0a01442@mail.gmail.com> <84fc9c000710110313n7d240731s3581d46bb5267f06@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00870.txt.bz2 On 10/13/07, Alexandre Oliva wrote: > > On Oct 11, 2007, "Richard Guenther" wrote: > >> The extra checking triggers PR33735. > > > Thanks. This is an interesting testcase. It is a variant of the > > problem H-P had reported, but I hadn't realized there was a lingering > > bug then. > > So the patch below reverts the work around for H-P's testcase, and > fixes the problem explained below. > > > The problem is that an exception thrown during stack unwinding is > > supposed to call terminate(), but AFAICT, when we inline the dtor of > > temporaries (other than the exception object) in the throw expression > > itself, calls that are brought in as part of the destructor get EH > > edges as if they were before the throw expression, escaping the > > requirement to call terminate in case they throw. > > > Now, since there aren't edges from the original dtor call to enclosing > > catch or clean-up points, when we look for such edges at the time of > > adjusting the PHI nodes, we don't find them. Oops. > > The patch below recognizes an ERT_ALLOWED_EXCEPTIONS EH region with an > empty type list and prevents the enclosing try block from being > regarded as reachable from within. With it, both testcases compile > correctly. > > libstdc++ builds with it; starting bootstrap and regtesting on > x86_64-linux-gnu right now. Ok to install? This is ok. Thanks, Richard.