From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lb0xk-0003ld-6K for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:08:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lb0xj-0003lJ-MR for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:08:47 -0500 Received: from [199.232.76.173] (port=33323 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lb0xj-0003lG-JC for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:08:47 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]:21869) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lb0xi-00071L-F0 for qemu-devel@nongnu.org; Sat, 21 Feb 2009 18:08:46 -0500 Received: by fg-out-1718.google.com with SMTP id e21so1898473fga.8 for ; Sat, 21 Feb 2009 15:08:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <49A05F5D.6070903@web.de> References: <20090221190054.12485.30486.stgit@mchn012c.ww002.siemens.net> <761ea48b0902211143x3f791ca8k5e6d0709076ce009@mail.gmail.com> <49A05F5D.6070903@web.de> Date: Sun, 22 Feb 2009 00:08:44 +0100 Message-ID: <761ea48b0902211508w75a0f6f2h20773f885db228f5@mail.gmail.com> Subject: Re: [Qemu-devel] Re: [PATCH 0/7] clean build - eliminate warnings From: Laurent Desnogues Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 Sat, Feb 21, 2009 at 9:09 PM, Jan Kiszka wrote: > Laurent Desnogues wrote: >> On Sat, Feb 21, 2009 at 8:00 PM, Jan Kiszka wrote: >>> When working on larger or intrusive changes like the monitor rework, th= e >>> number of warnings a normal build generates (here: x86-64 host, gcc 4.3= ) >>> is still too high. And sometimes these warnings are not just of cosmeti= c >>> nature, see (reposted) patch 3. >>> >>> This series reduces the number of warnings significantly, still not to >>> zero (someone would have to look into the NetWinder stuff), but almost: >>> >>> Warning summary for 2009-02-21 (changes since 2009-02-21-base) >>> generic 0 (-1) >>> softmmu 0 (-39) >>> x86 0 (0) >>> arm 0 (-10) >> >> This means that after applying your patch there should be no more >> warning for the ARM target? > > At least for softmmu, at least with my compiler (depending on the > precise version / distro patches, you may have different warnings > enabled by default): yes. I built softmmu and my Makefile has no other warning than the default. >> >> On my machine (x86_64, gcc 4.1.2), I still get these: >> >> CC arm-softmmu/neon_helper.o >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c: In >> function =91helper_neon_rshl_s8=92: >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:469: >> warning: =91vdest.v1=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:469: >> warning: =91vdest.v2=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:469: >> warning: =91vdest.v3=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:469: >> warning: =91vdest.v4=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c: In >> function =91helper_neon_rshl_s16=92: >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:470: >> warning: =91vdest.v1=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:470: >> warning: =91vdest.v2=92 is used uninitialized in this function >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c: In >> function =91helper_neon_rshl_s32=92: >> /home/ldesnogu/work/Emu/qemu/svn-ref/target-arm/neon_helper.c:471: >> warning: =91vdest.v1=92 is used uninitialized in this function > > Has this been identified as a real issue or just compiler blindness (my > series contains one "fix" for such blindness, see cris patch)? I'm > currently a bit lost in those macros... Yes, it's a real bug: dest has not been given a value. You can look at preprocessed code :-) BTW, can gcc really say a value is used uninitialized? I have seen it pretending "may be used uninitialized" though it is, but it was always right when it says "is used uninitialized". >> >> Note a patch has been proposed in the past (by Aur=E9lien IIRC). > > Do you have a reference at hand? Try this: http://article.gmane.org/gmane.comp.emulators.qemu/31206 HTH, Laurent