From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: Build errors with latest xen-unstable from staging Date: Mon, 7 Feb 2011 15:39:24 +0100 Message-ID: <4D50041C.5060907@amd.com> References: <4D4EF01F.5050106@gmail.com> <1297072022.13091.753.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1297072022.13091.753.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Kamala Narasimhan , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Ian Campbell wrote: > On Sun, 2011-02-06 at 19:01 +0000, Kamala Narasimhan wrote: >> FYI - Pulled the latest xen-unstable from staging to sync some patches= and got >> these trivial errors while compiling - >> >> xl_cmdimpl.c: In function =E2=80=98print_domain_vcpuinfo=E2=80=99: >> xl_cmdimpl.c:3351: warning: =E2=80=98firstset=E2=80=99 may be used uni= nitialized in this function >> xl_cmdimpl.c:3351: note: =E2=80=98firstset=E2=80=99 was declared here >> xl_cmdimpl.c:3350: warning: =E2=80=98bitmask=E2=80=99 may be used unin= itialized in this function >> xl_cmdimpl.c:3350: note: =E2=80=98bitmask=E2=80=99 was declared here >> xl_cmdimpl.c:3350: warning: =E2=80=98pmap=E2=80=99 may be used uniniti= alized in this function >> xl_cmdimpl.c:3350: note: =E2=80=98pmap=E2=80=99 was declared here >> >> GCC version - 4.2.4. Initializing the three variables it complained a= bout fixed >> the issue. >=20 > They are actually initialised before use, during the first pass through > the for loop when i=3D=3D0 and state=3D=3D0, but I can see how gcc woul= d be > unable to figure that out (in fact I'm not sure about firstset myself). I agree with Ian, looking through the code again I can confirm that they=20 are _not_ used uninitialized. Even firstset is set when the state=20 switches from 0 to 1 and is only used later in state 1 and 3, so it is sa= fe. It seems like the compiler is not smart enough to recognize this,=20 especially the modulo operation could be a barrier for the analysis, I=20 think. According to the manpage those warning are only emitted on -O, which I=20 left out for my testing, so I didn't spot this warning. Sorry. To appease the compiler I would ack the fix, though from an academic=20 point of view it is not necessary. > In the Linux kernel they have a macro to annotate such instances: > /* > * A trick to suppress uninitialized variable warning without g= enerating any > * code > */ > #define uninitialized_var(x) x =3D x > =20 > Do we want something similar? I don't think so. x =3D x looks more like a hack, if we can easily=20 initialize the variables, we should do so. Regards, Andre. >=20 >> If this trivial change should require a signed off line, here it is >> - Signed-off-by: Kamala Narasimhan >=20 > Always just assume a change does. >=20 > Ian. >> diff -r 7ada6faef565 tools/libxl/xl_cmdimpl.c >> --- a/tools/libxl/xl_cmdimpl.c Sun Feb 06 17:26:31 2011 +0000 >> +++ b/tools/libxl/xl_cmdimpl.c Sun Feb 06 13:53:50 2011 -0500 >> @@ -3347,8 +3347,8 @@ static void print_bitmap(uint8_t *map, i >> static void print_bitmap(uint8_t *map, int maplen, FILE *stream) >> { >> int i; >> - uint8_t pmap, bitmask; >> - int firstset, state =3D 0; >> + uint8_t pmap =3D 0, bitmask =3D 0; >> + int firstset =3D 0, state =3D 0; >> >> for (i =3D 0; i < maplen; i++) { >> if (i % 8 =3D=3D 0) { >> >> Kamala >> --=20 Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany