From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv5p6-0006Ko-5p for qemu-devel@nongnu.org; Mon, 23 Dec 2013 08:45:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vv5p1-0008Eb-4M for qemu-devel@nongnu.org; Mon, 23 Dec 2013 08:45:31 -0500 Received: from cantor2.suse.de ([195.135.220.15]:39485 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vv5p0-0008EC-An for qemu-devel@nongnu.org; Mon, 23 Dec 2013 08:45:26 -0500 Message-ID: <52B83E70.80904@suse.de> Date: Mon, 23 Dec 2013 14:45:20 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <20131223115622.GA6490@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-arm: fix build on fedora List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: John Rigby , "Michael S. Tsirkin" , Alexander Graf , QEMU Developers , Laszlo Ersek , Richard Henderson Am 23.12.2013 13:37, schrieb Peter Maydell: > On 23 December 2013 11:56, Michael S. Tsirkin wrote: >> commit 5ce4f35781028ce1aee3341e6002f925fdc7aaf3 >> "target-arm: A64: add set_pc cpu method" >> >> introduces an array aarch64_cpus which is zero >> size if this code is built without CONFIG_USER_ONLY. >> In particular an attempt to iterate over this array produces a warning= : >> >> CC aarch64-softmmu/target-arm/cpu64.o >> /scm/qemu/target-arm/cpu64.c: In function =E2=80=98aarch64_cpu_registe= r_types=E2=80=99: >> /scm/qemu/target-arm/cpu64.c:124:5: error: comparison of unsigned >> expression < 0 is always false [-Werror=3Dtype-limits] >> for (i =3D 0; i < ARRAY_SIZE(aarch64_cpus); i++) { >> ^ >> cc1: all warnings being treated as errors >> >> This is the result of ARRAY_SIZE being an unsigned type, >> causing i to be promoted to unsigned int as well. >=20 > I guess this is a new gcc warning, since this all builds > fine for me (gcc 4.6.3). No problem noticed with 4.8.1 on today's master either. >> As zero size arrays are a gcc extension, it seems >> cleanest to add a dummy element with NULL name, >> and test for it during registration. >> >> Cc: Alexander Graf >> Cc: Peter Maydell >> Cc: Richard Henderson >> Signed-off-by: Michael S. Tsirkin >> --- >> >> I have queued this in my tree since it prevents me from >> being able to build and test properly. >> Pls review and ack. >> >> target-arm/cpu64.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c >> index 04ce879..2efe189 100644 >> --- a/target-arm/cpu64.c >> +++ b/target-arm/cpu64.c >> @@ -58,6 +58,7 @@ static const ARMCPUInfo aarch64_cpus[] =3D { >> #ifdef CONFIG_USER_ONLY >> { .name =3D "any", .initfn =3D aarch64_any_initfn }, >> #endif >> + { .name =3D NULL } >> }; >> >> static void aarch64_cpu_initfn(Object *obj) >> @@ -100,6 +101,10 @@ static void aarch64_cpu_register(const ARMCPUInfo= *info) >> .class_init =3D info->class_init, >> }; >> >> + if (!info->name) { >> + return; >> + } >> + >> type_info.name =3D g_strdup_printf("%s-" TYPE_ARM_CPU, info->name= ); >> type_register(&type_info); >> g_free((void *)type_info.name); >=20 > At a minimum, if we take this approach we should add TODO comments > to the effect that the NULL terminator and the if() can be removed > when the first real AArch64 CPU is added. >=20 > I think I'd rather put the if (!info->name) continue into the function > which is doing the looping over the array. While I share your sentiment wrt this workaround, what's the status of getting a real 64-bit CPU applied? Isn't the Cortex-A57/A53 CPU independent of whether we have all MPCore etc. pieces in place? That would seem the most elegant solution to me, even if not "usable" yet. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg