From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KkKnK-0001EK-GQ for qemu-devel@nongnu.org; Mon, 29 Sep 2008 11:36:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KkKnI-0001E8-4n for qemu-devel@nongnu.org; Mon, 29 Sep 2008 11:36:17 -0400 Received: from [199.232.76.173] (port=50217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KkKnH-0001E5-Vb for qemu-devel@nongnu.org; Mon, 29 Sep 2008 11:36:16 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:59341) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KkKnI-0004Yn-95 for qemu-devel@nongnu.org; Mon, 29 Sep 2008 11:36:16 -0400 Received: by gxk12 with SMTP id 12so11500753gxk.10 for ; Mon, 29 Sep 2008 08:36:15 -0700 (PDT) Message-ID: Date: Mon, 29 Sep 2008 18:36:14 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] latest svn sparc-softmmu compile warnings In-Reply-To: <48E0BB10.2050201@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48E0205B.40205@earthlink.net> <48E0228B.7060405@earthlink.net> <48E08F44.6030301@opensuse.org> <48E0BB10.2050201@earthlink.net> 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 9/29/08, Robert Reif wrote: > Martin Mohring wrote: > > > Still get this on i586 host for tcg-dyngen.c on i586, arm, cris, m68k.... > Using svn trunk -r 5349 here. host os openSUSE 11.0, kernel headers host > 2.6.25. > > > > > > > It turns out patch 5174 introduced this warning. > The following patch fixes it but I don't know if its the best way to fix > it. Please see my comments from time before committing r5174: http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg01355.html As the emulators worked fine before defining TARGET_LONG_BITS, the patch may or may not be correct. I don't know. If I did, the warning would be trivial to fix or suppress. Now the warning highlights a potential bug, much like the slirp pointer truncation warnings indicate a real bug.