From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItDs9-0000tc-JL for qemu-devel@nongnu.org; Fri, 16 Nov 2007 21:57:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItDs8-0000qJ-2y for qemu-devel@nongnu.org; Fri, 16 Nov 2007 21:57:29 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItDs7-0000q5-M7 for qemu-devel@nongnu.org; Fri, 16 Nov 2007 21:57:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ItDs7-0007zQ-5I for qemu-devel@nongnu.org; Fri, 16 Nov 2007 21:57:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ItDrv-0007Zk-5I for qemu-devel@nongnu.org; Sat, 17 Nov 2007 02:57:15 +0000 Received: from 76.14.48.172 ([76.14.48.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Nov 2007 02:57:15 +0000 Received: from blp by 76.14.48.172 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Nov 2007 02:57:15 +0000 From: Ben Pfaff Date: Fri, 16 Nov 2007 18:58:45 -0800 Message-ID: <87bq9tk26y.fsf@blp.benpfaff.org> References: <1195168693.2415.19.camel@rapid> <200711161552.55645.paul@codesourcery.com> <1195229132.28318.10.camel@jma4.dev.netgem.com> <1195257843.5335.15.camel@rapid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: news Subject: [Qemu-devel] Re: RFC: fix for random Qemu crashes Reply-To: blp@cs.stanford.edu, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org "J. Mayer" writes: > On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: >> I think a line like >> >> #define inline __attribute__ (( always_inline )) inline >> >> in dyngen-exec.h should be > > As I already pointed it in the first message of the thread, this kind of > define would expand recursivelly, [...] No. A macro is not expanded within its own expansion. See ISO C99: 6.10.3.4 Rescanning and further replacement [...] 2 If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. If it still bothers you, you could write it as #define inline __attribute__ (( always_inline )) __inline__ since GCC accepts __inline__ as a synonym for inline. -- Ben Pfaff http://benpfaff.org