From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4031 invoked by alias); 27 Nov 2003 09:43:03 -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 3915 invoked from network); 27 Nov 2003 09:43:00 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 27 Nov 2003 09:43:00 -0000 Received: by nondot.org (Postfix, from userid 501) id 7A0C317C035; Thu, 27 Nov 2003 04:43:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id 7023324C299; Thu, 27 Nov 2003 03:43:10 -0600 (CST) Date: Thu, 27 Nov 2003 10:15:00 -0000 From: Chris Lattner To: Zack Weinberg Cc: Andrew Haley , , Jim Wilson , Subject: Re: avoid unnecessary register saves for setjmp In-Reply-To: <87ekvuup4s.fsf@egil.codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-11/txt/msg02148.txt.bz2 On Thu, 27 Nov 2003, Zack Weinberg wrote: > >From a language-design perspective it's desirable for x to have the > value 23 in both fragments. (Leaving out the volatile on x is > intentional.) Its being undefined in C is a source of hard-to-find > bugs. It happens because longjmp() can't know which registers need > restoring, whereas the EH unwinder does know and can get it > (abstractly) right. So by using the EH unwinder for longjmp we clean > up a nasty dark corner of the language. Also, ideally, longjmp should run cleanups in intervening stackframes, which the LLVM implementation does, just like for pthreads cancellation. > To be fair, an argument against this change is that it would break > code that uses setjmp and longjmp to implement coroutine linkage. > (The set/get/make/swapcontext calls are better for this, but that > doesn't mean everyone uses them.) I don't believe that this is actually legal ANSI C. You can only return to a place that has been setjmp'd to, there is no way to 'construct' a jmpbuf. Likewise, you cannot setjmp, return from the setjmp'ing function, then longjmp back to the 'dead' jmpbuf. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/