From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOpeR-0007Ov-5U for qemu-devel@nongnu.org; Fri, 20 Feb 2015 10:38:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOpeN-0006dd-87 for qemu-devel@nongnu.org; Fri, 20 Feb 2015 10:37:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOpeM-0006dH-VW for qemu-devel@nongnu.org; Fri, 20 Feb 2015 10:37:55 -0500 Date: Fri, 20 Feb 2015 16:37:49 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150220153748.GB18126@potion.brq.redhat.com> References: <1424441905-5735-1-git-send-email-rkrcmar@redhat.com> <1424441905-5735-3-git-send-email-rkrcmar@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] milkymist-pfpu: fix GCC 5.0.0 aggressive-loop-optimizations warning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Michael Walle , QEMU Developers 2015-02-20 23:40+0900, Peter Maydell: > On 20 February 2015 at 23:18, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > man gcc: > > Warn if in a loop with constant number of iterations the compiler > > detects undefined behavior in some statement during one or more of > > the iterations. > > > > Refactored the code a bit to avoid the GCC warning, in an objectionab= le > > way, > > hw/misc/milkymist-pfpu.c: In function =E2=80=98pfpu_write=E2=80=99: > > hw/misc/milkymist-pfpu.c:365:20: error: loop exit may only be reach= ed after undefined behavior [-Werror=3Daggressive-loop-optimizations] > > if (i++ >=3D MICROCODE_WORDS) { > > ^ > > hw/misc/milkymist-pfpu.c:167:14: note: possible undefined statement= is here > > uint32_t insn =3D s->microcode[pc]; > > ^ >=20 > Why can't we just fix this by fixing the loop boundary > condition, which is the actual bug here? There should > be no need to move the check into the function (where it > does not belong). It would work now, but GCC could get more intelligent with time and realize that there still can be undefined behavior ... > (We try to stop before overflowing the s->microcode[] > array, but because 'i++' is a post increment and we do a >=3D > comparison, the last loop round will try to write to > s->microcode[MICROCODE_WORDS]. Easiest fix is to use > "++i" I suppose, though it might be better to just > separate the increment and the conditional instead.) >=20 > There is probably some actual hardware behaviour we're > failing to model correctly here, since it's a safe bet > the h/w doesn't print an error message in this situation. > However we should just fix the bogus array handling for now. Ok, I will do just ++i for v2 and keep the other bug for later.