From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3401 invoked by alias); 8 Nov 2002 01:29:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 3391 invoked from network); 8 Nov 2002 01:29:14 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 8 Nov 2002 01:29:14 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id gA81QcJ25566; Thu, 7 Nov 2002 17:26:38 -0800 Date: Thu, 07 Nov 2002 17:29:00 -0000 From: Mark Mitchell To: Jakub Jelinek cc: Richard Henderson , Geoff Keating , "zack@codesourcery.com" , "aldyh@redhat.com" , "gcc-patches@gcc.gnu.org" , "jason@redhat.com" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests Message-ID: <139070000.1036718798@warlock.codesourcery.com> In-Reply-To: <20021107200942.X10988@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-11/txt/msg00528.txt.bz2 > You mean statically into .gcc_except_table, or dynamically? > Statically could be doable through some builtin and some hacks, > dynamically would be way harder. I meant statically -- a "you have to check to see if I might have registered anything" bit. > That's why the proposal is about __try/__finally only, not __except > where it is e.g. not clear at all what happens if you throw in C++ > and __except control expression returns -1. > At least from what I read in MSFT docs on the web, their __try/__finally > matches Aldy's patch. Except that it also handles asynchronous exceptions, which ours doesn't. Where we'd get a SIGFPE you get a structured exception in Microsoft's stuff. >> I would prefer longjmp_unwind; that's something we're supposed to >> have anyhow, and it would be very useful in making existing C >> libraries play more nicely with C++, so implementing that would be >> a definite win. > > longjmp_unwind would be good to have. Well, we all seem to agree on that. So, if we can do it that way, we get a definitively useful feature required by the ABI, and we don't open a can of worms on the language side. If it's really too dang slow, we can do something different. On the other hand, you'll have avoided adding frame information to every C program, which is a big win on space, and something our C users have told us they don't want in the past. And you can avoid the setjmps if you write your code in C++; there you can use the resource-acquisition-as-initialization idiom. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com