From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26635 invoked by alias); 7 Nov 2002 20:36:09 -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 26627 invoked from network); 7 Nov 2002 20:36:08 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 7 Nov 2002 20:36:08 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gA7Ka4J07894; Thu, 7 Nov 2002 15:36:04 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5) with ESMTP id gA7Ka3u4026753; Thu, 7 Nov 2002 18:36:03 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5/Submit) id gA7Ka1vX026749; Thu, 7 Nov 2002 18:36:01 -0200 To: Aldy Hernandez Cc: Fergus Henderson , Jakub Jelinek , Geoff Keating , Richard Henderson , "gcc-patches@gcc.gnu.org" , "jason@redhat.com" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests References: <20021106124304.G10988@devserv.devel.redhat.com> <8450000.1036625540@warlock.codesourcery.com> <20021107000307.GQ22215@redhat.com> <20021107112921.GA14780@ceres.cs.mu.oz.au> <20021107072246.M10988@devserv.devel.redhat.com> <20021107131331.GA8648@ceres.cs.mu.oz.au> <20021107165519.GC28497@redhat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Thu, 07 Nov 2002 12:36:00 -0000 In-Reply-To: <20021107165519.GC28497@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00498.txt.bz2 On Nov 7, 2002, Aldy Hernandez wrote: >> But I would like the support for exception handling to include support >> for throwing and catching exceptions, not just try/finally. The current >> proposal seems too limited to be useful for much else than glibc, IMHO. > How are you going to handle catching exceptions, given that we have no > way to recognize certain types in C (templates, classes, etc)? You don't recognize types. You just catch everything. Which sounds perfectly reasonable from a C standpoint. One of the things I liked about the C front-end of GCC was that it could pretty much exercise any of the features available to all other languages: nested functions, so that you could do the same as Pascal; extended inline assembly, such that you didn't have to fallback to assembly for everything; variable-sized types, like some other languages support; expression statements, etc, etc. The nice thing was that C could really be used as a high-level assembly, exercising most (if not all) of the internal features the back-end would have to implement for other languages anyway. This broke down when Ada and C++ introduced exceptions as language-specific extensions, and then, even though C++ exceptions were later integrated into the generic back end framework, they were still unavailable in C. I personally think cleanups are a step in the right direction of restoring the ability to exercise all features of the compiler in a single front end. I don't really care if it's C, C++, treelang or something else, but clearly to me C++ is not a good candidate since it fails to support a number of other gcc extensions that the C front end supports. So I'm all for bringing back-end-supported exception handling support features into our higher-level assembly. I wouldn't go as far as supporting catches and throws right now, given that we don't have a clean design for this feature, but try/finally looks terrifically simple, and it's not like it's a new idea: as many others have pointed out, other compilers already support it, so it's likely to gain acceptance in the next round of C standardization. Even more so if we choose to support it exactly like other compilers do. The other advantage I see in offering not only clean-ups, but actual exception catching and throwing in our high-level assembly, is that we can then write glue code to convert exceptions from one language to another. Currently, there's really no simple way to do it, to the best of my knowledge. I'm not saying writing such glue code would be simple, but at least someone wouldn't have to write such glue as a number of functions that call one-another, each one implemented in a separate exception-supporting language. Being able to unify the EH framework and expose it to the user would even enable us to implement EH supporting routines for languages in our higher-level assembly. But then, again, for actual exception handling, we still need more discussion and design, but for clean ups, there's really not much possibility for variation in the design and syntax, and following existing practice in other compilers and languages is clearly a plus. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer