From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbCDk-0008JJ-LA for qemu-devel@nongnu.org; Sun, 22 Feb 2009 06:10:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbCDi-0008I4-U4 for qemu-devel@nongnu.org; Sun, 22 Feb 2009 06:10:04 -0500 Received: from [199.232.76.173] (port=36490 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbCDi-0008I1-Gm for qemu-devel@nongnu.org; Sun, 22 Feb 2009 06:10:02 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:35758) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbCDh-0006gj-Vc for qemu-devel@nongnu.org; Sun, 22 Feb 2009 06:10:02 -0500 Message-ID: <49A13287.9070008@web.de> Date: Sun, 22 Feb 2009 12:09:59 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20090221190054.12485.30486.stgit@mchn012c.ww002.siemens.net> <761ea48b0902211143x3f791ca8k5e6d0709076ce009@mail.gmail.com> <49A05F5D.6070903@web.de> <761ea48b0902211508w75a0f6f2h20773f885db228f5@mail.gmail.com> <49A12B4A.9040901@web.de> In-Reply-To: <49A12B4A.9040901@web.de> Content-Type: text/plain; charset=windows-1252 Sender: jan.kiszka@web.de Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH 0/7] clean build - eliminate warnings 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 Cc: Paul Brook , Aurelien Jarno Jan Kiszka wrote: > Laurent Desnogues wrote: >> 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 wrot= e: >>>>> When working on larger or intrusive changes like the monitor rework= , the >>>>> 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 cos= metic >>>>> 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 alm= ost: >>>>> >>>>> 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 :-) >=20 > Yeah, preprocessed and Lindent'ed, this looks really buggy. >=20 >> 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". >=20 > Obviously, detecting uninitialized variables with gcc still leaves room > for improvement. Version 4.3 actually seem to have regressed in this ca= se. >=20 >>>> 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 >=20 > OK, that makes sense, partially. My feeling is that there are some more > typos/thinkos in this code. First, the macro for 8/16/32 bit checks for > a shift width of -8/-16/-32, but the 64-bit version uses -63?! And then > we have this (for signed rshl): >=20 > dest =3D src >> (width - 1); > dest++; > dest >>=3D 1; >=20 > Looks like nothing else than dest =3D 0, no? Paul? One more: [NEON_FN for rshl_s8/16/32] ... } else if (tmp =3D=3D -sizeof(src1) * 8) { \ dest =3D src1 >> (tmp - 1); \ ie. if (tmp =3D=3D -8/-16/-32) { dest =3D src1 >> (-9/-17/-33); Jan