From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItIwe-0001g2-C4 for qemu-devel@nongnu.org; Sat, 17 Nov 2007 03:22:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItIwX-0001fi-Vn for qemu-devel@nongnu.org; Sat, 17 Nov 2007 03:22:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItIwW-0001ff-6v for qemu-devel@nongnu.org; Sat, 17 Nov 2007 03:22:21 -0500 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ItIwV-0005uh-RI for qemu-devel@nongnu.org; Sat, 17 Nov 2007 03:22:20 -0500 Received: from bangui.magic.fr ([195.154.194.245]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ItIwU-00039r-JK for qemu-devel@nongnu.org; Sat, 17 Nov 2007 03:22:18 -0500 Subject: Re: [Qemu-devel] Re: RFC: fix for random Qemu crashes From: "J. Mayer" In-Reply-To: <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> <87bq9tk26y.fsf@blp.benpfaff.org> Content-Type: text/plain Date: Sat, 17 Nov 2007 09:22:06 +0100 Message-Id: <1195287727.5335.24.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: blp@cs.stanford.edu, qemu-devel@nongnu.org On Fri, 2007-11-16 at 18:58 -0800, Ben Pfaff wrote: > "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: I just take a look of what happens in *real life* while compiling the linux kernel which uses such a definition.... As I reported, I had compilation problems due to this behavior and did inspect the preprocessor output and saw this result. I did not check if it happens only with some versions of gcc or if this behavior has been changed with newer releases, I have to admit. > > 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. You're right, this would be a good solution to avoid many changes in the code. -- J. Mayer Never organized