From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3570 invoked by alias); 27 Nov 2003 15:33:53 -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 3370 invoked from network); 27 Nov 2003 15:33:49 -0000 Received: from unknown (HELO mail.esmertec.com) (195.141.71.133) by sources.redhat.com with SMTP; 27 Nov 2003 15:33:49 -0000 To: Chris Lattner Cc: gcc-patches@gcc.gnu.org Subject: Re: avoid unnecessary register saves for setjmp References: <87ekvuup4s.fsf@egil.codesourcery.com> From: Jan Vroonhof Date: Thu, 27 Nov 2003 16:23:00 -0000 Message-ID: <5cad8ef043da68f2a3332f00bd6a186a3fc6195a@mail.esmertec.com> In-Reply-To: (Chris Lattner's message of "Thu, 27 Nov 2003 03:43:10 -0600 (CST)") MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg02168.txt.bz2 The following message is a courtesy copy of an article that has been posted to gmane.comp.gcc.patches as well. Chris Lattner writes: >> 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.) Doesn't it also convert longjmp from an O(1) in to an O(nr off stack frames) operation? > > 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. It might not be ANSI C, but it does work on most systems for user level threading (essentially implementing swapcontext by direct manipulation of the jmbuf). There is lots of useful things people do with C that are not strictly ANSI/ISO C. In fact that kind of low level control is often exactly the reason to use C in the first place. Jan