From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CgAAb-0004YB-E2 for qemu-devel@nongnu.org; Sun, 19 Dec 2004 18:08:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CgAAa-0004Xf-HX for qemu-devel@nongnu.org; Sun, 19 Dec 2004 18:08:56 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CgAAa-0004XU-BT for qemu-devel@nongnu.org; Sun, 19 Dec 2004 18:08:56 -0500 Received: from [38.113.3.61] (helo=smtp-out.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cg9zy-0006tq-9O for qemu-devel@nongnu.org; Sun, 19 Dec 2004 17:57:58 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 4F193BE6CDA for ; Sun, 19 Dec 2004 22:57:48 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-3.hotpop.com (Postfix) with ESMTP id 9B0B51294D56 for ; Sun, 19 Dec 2004 22:57:44 +0000 (UTC) Date: Sun, 19 Dec 2004 17:57:43 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host Message-ID: <20041219225743.GA18362@jbrown.mylinuxbox.org> References: <20041215145903.GA29957@100tka.net> <20041215234503.GA12778@jbrown.mylinuxbox.org> <20041217195627.A38776@saturn.kn-bremen.de> <20041218040428.GA31934@jbrown.mylinuxbox.org> <20041218155037.GA32132@jbrown.mylinuxbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: 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 On Sun, Dec 19, 2004 at 03:25:26PM +0100, Johannes Schindelin wrote: > Hi, > > On Sat, 18 Dec 2004, Jim C. Brown wrote: > > > Originally, the op_* functions for qemu were written so that they would > > have the machine code and then the rets at the very end of the function. > > qemu could then just chain them together by stripping the rets. > > > > gcc now rearranges the generated code around, and reserves the right to > > stick in extra rets any place it wants, not just the very end, which > > makes them very hard to strip off. > > IIRC there was a flag to gcc to prevent just this. > > Ciao, > Dscho > AFAIK, there was no such flag. Apparently, you can't have such a flag, due to the redesign of the gcc optimizer. Of course, that was said to me a while ago ... it may be that someone manged to nag the gcc team enough to get them to add this flag just for us. If that is so, we just need to add that flag to the makefiles. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.