From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones Subject: Re: [kvm-unit-tests PATCH] Replace -Wextra with a saner list of warning flags Date: Thu, 29 Jun 2017 18:35:47 +0200 Message-ID: <20170629163547.7wp4fzmgb4e4y7tq@kamzik.brq.redhat.com> References: <1498750826-7902-1-git-send-email-thuth@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Paolo Bonzini , David Hildenbrand , Radim =?utf-8?B?S3LEjW3DocWZ?= , Laurent Vivier To: Thomas Huth Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58438 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbdF2Qfy (ORCPT ); Thu, 29 Jun 2017 12:35:54 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4BD0E73B3C for ; Thu, 29 Jun 2017 16:35:54 +0000 (UTC) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 29, 2017 at 06:30:47PM +0200, Thomas Huth wrote: > On 29.06.2017 17:40, Thomas Huth wrote: > > Using -Wextra together with -Werror is troublesome - various versions > > of GCC produce suspicious or even wrong warnings with -Wextra which > > then become fatal errors with -Werror. For example, the current state > > of the kvm-unit-tests does not compile anymore with GCC 4.8.1 for > > s390x due to an inadequate -Wmissing-field-initializers warning. > > That's annoying for users who just would like to compile the > > kvm-unit-tests and cumbersome for the developers who have to work > > around these problems in the source code. So let's replace -Wextra > > by a saner lists of warning flags that are normally enabled by -Wextra. > > Most of them are added to the architecture independent CFLAGS list, > > so that x86 now benefits from these checks, too. The ones that > > could not be added there are placed in the architecture specific > > CFLAGS instead. > > BTW, I also dropped -Wunused-parameter on purpose. It's often a nuisance > that you are forced to add "unused" attributes to parameters, just > because you can not get rid of certain parameter since your function has > to obey a certain API. That means we could now finally also get rid of > the ugly "__unused" tags in the code in the lib folder again, if we like ;-) Fine by me. Adding __unused gets tiresome and ugly. I even recently wrote a patch where I needed to introduce __maybe_unused... Thanks, drew