From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRCvc-0003Hk-9L for qemu-devel@nongnu.org; Mon, 18 Feb 2008 15:49:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRCva-0003Fl-9j for qemu-devel@nongnu.org; Mon, 18 Feb 2008 15:49:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRCva-0003Fc-5W for qemu-devel@nongnu.org; Mon, 18 Feb 2008 15:49:30 -0500 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JRCvZ-0000zF-DF for qemu-devel@nongnu.org; Mon, 18 Feb 2008 15:49:29 -0500 Date: Mon, 18 Feb 2008 20:49:26 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] Patch for compiling with GCC 4 Message-ID: <20080218204926.GE4747@networkno.de> References: <200802162001.02410.paul@codesourcery.com> <2151CED4-02CD-4928-978A-6C63A734F19F@csgraf.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2151CED4-02CD-4928-978A-6C63A734F19F@csgraf.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, Paul Brook Alexander Graf wrote: > > On Feb 17, 2008, at 9:22 PM, Christian Roue wrote: > >> Well, I somehow felt like it was a bit brutal and probably fixing the >> symptoms which is apparently the case. >> Looking more carefully, compile fails in : >> sh4-linux-user for function op_cmp_str_T0_T1 >> gcc optimization leads to a ret followed by a last assignement with a >> jump back. >> I guess dyngen hopes to find function epilogue as the last bytes. >> It's apparently the only function where it happens. >> >> I found that adding gcc option "-fno-tree-dominator-opts" for sh4 >> target avoids this (I suppose) unwanted optimization. >> It may be a bit brutal again ( disabling too many optims or wrong >> ones). >> May be the op_cmp_str_T0_T1 function can be rewritten to something >> that avoids this optimization. >> Am I on a better track ? > > This looks like the right approach to the symptoms. The "real fix" would > be to move the sh4 target to TCG, The migration to tcg can be done gradually, fixing the immediate problem shouldn't get too involved. > but for the meantime I believe this is > the way to go. You can already find a lot of these unoptimization flags > autodetected in the configure script, so I guess that'd be the right > place for a patch. I added those as workarounds, they should rather go away than expand to cover even more flags. Thiemo