From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYMLq-000859-Eg for qemu-devel@nongnu.org; Wed, 18 Mar 2015 18:22:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYMLl-0004LO-CB for qemu-devel@nongnu.org; Wed, 18 Mar 2015 18:22:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYMLl-0004LC-3L for qemu-devel@nongnu.org; Wed, 18 Mar 2015 18:22:05 -0400 Message-ID: <5509FA88.3000201@redhat.com> Date: Wed, 18 Mar 2015 18:22:00 -0400 From: John Snow MIME-Version: 1.0 References: <550880E5.8020505@redhat.com> <5508879E.2050809@redhat.com> <5509D06E.4060507@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] clang 3.5.0 errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel , Stefan Hajnoczi On 03/18/2015 04:28 PM, Peter Maydell wrote: > On 18 March 2015 at 19:22, John Snow wrote: >> There's one case of error here that's interesting that ccache unearths: >> >> we use a gnu extension to give return values to compound statement blocks, >> then wrap these blocks into macros as if they were functions. >> >> The practical outcome here is that these blocks have return codes that we >> often don't check, so clang will spit out "unused value" warnings if we >> compile these after preprocessing, like ccache will tend to do. >> >> This warning is potentially valid: if these calls can fail, we should >> probably either be asserting that a failure did not occur OR we should >> switch to a variant without a return code, if failure is impossible in these >> locations. >> >> An example of this is in linux-user/elfload.c where we define the >> NEW_AUX_ENT() macro which in turn uses the put_user_ual(val, sp) macro. When >> this is expanded, it turns into a compound statement where we discard the >> expression result, so clang whines. >> >> Of course, this all goes away if you disable ccache, but is it worth >> adjusting this particular usage anyway? > > I agree that ideally we wouldn't do that, but why is this > only visible via ccache? If ccache creates warnings that > aren't visible when directly running the c compiler then > that's a bug in ccache even if the warnings are in theory > interesting. > You're asking the hard questions. My hunch is that when the macro is functionaized like it is, clang's static analysis treats it as such and decides not to warn about not checking the return code, much like it won't for real functions. When it's flattened, it loses its semantic nature as a function and it becomes more of a "useless statement" warning. It's definitely a bug in ccache, clang or both. I just found this particular instance of a ccache-provoked warning interesting because it does have some validity to it and I wanted to raise the issue. If nobody cares, then, well. Nobody cares. More mechanical, less-interesting clang fixes will hit the list shortly. --js