From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lb11t-00068A-3y for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:13:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lb11s-00066q-7B for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:13:04 -0500 Received: from [199.232.76.173] (port=53653 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lb11s-00066e-2c for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:13:04 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]:18847) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lb11r-0007aD-QI for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:13:04 -0500 Received: by fg-out-1718.google.com with SMTP id e21so1899006fga.8 for ; Sat, 21 Feb 2009 15:13:02 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20090221230359.GA19611@miranda.arrow> References: <20090221190054.12485.30486.stgit@mchn012c.ww002.siemens.net> <20090221190055.12485.92159.stgit@mchn012c.ww002.siemens.net> <20090221230359.GA19611@miranda.arrow> Date: Sun, 22 Feb 2009 00:13:02 +0100 Message-ID: <761ea48b0902211513h12ddaf09x4dab923f8512a128@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 5/7] clean build: Fix remaining cris warnings From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 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: qemu-devel@nongnu.org On Sun, Feb 22, 2009 at 12:03 AM, Stuart Brady wrote: > On Sat, Feb 21, 2009 at 08:00:55PM +0100, Jan Kiszka wrote: >> diff --git a/target-cris/translate.c b/target-cris/translate.c >> index f575e63..954b038 100644 >> --- a/target-cris/translate.c >> +++ b/target-cris/translate.c >> @@ -2613,7 +2613,7 @@ static unsigned int dec_move_pm(DisasContext *dc) >> static unsigned int dec_movem_mr(DisasContext *dc) >> { >> TCGv_i64 tmp[16]; >> - TCGv tmp32; >> + TCGv tmp32 = 0; >> TCGv addr; >> int i; >> int nr = dc->op2 + 1; > > Hmm, GCC just gets it wrong here -- and 0 isn't really very meaningful. > At the very least, shouldn't there be a comment? Something like Linux's > uninitialized_var() macro might be worth considering... Some targets use TCGV_UNUSED_I32/I64. I would initialize tmp32 to that value in an additional else part to the first if (nr & 1). That should silence gcc. Laurent