From patchwork Wed Jul 12 03:41:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 786964 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3x6l9S1LxJz9s8P for ; Wed, 12 Jul 2017 13:41:16 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ZO/ASQZ9"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933034AbdGLDlN (ORCPT ); Tue, 11 Jul 2017 23:41:13 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:33699 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932475AbdGLDlL (ORCPT ); Tue, 11 Jul 2017 23:41:11 -0400 Received: by mail-oi0-f44.google.com with SMTP id p188so9601031oia.0; Tue, 11 Jul 2017 20:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aQl9dzOLW6gwgXurnGb3tJ3kjSN10KfXFeW4HLDAnSI=; b=ZO/ASQZ9XVvWYJc/OyZ37R1PuUAQKlu/mroopEncty2ty7Avu4PswRdmrv+lH5VpyX yo/CV73lnrTBEiEh3ambHWzH4l9M94G0BnbkM27J6vdsnRCkTgz7POD2nq+l+Tdbg/VK 9WyENEdtPQwCp1p2miOgdif+JSSoWCkeTRC7O8jASeDg6pCPhz6CPDGIPKZG7t4gFwhJ BXLRKOsWSsDOMvDt/05NwmudlDSyprtg7m/Tlj5nKPTihsATtFxdBOKkbUT3FAo8YmsM gcj8rXf7xcemxo42/s8z7kdH1zm7lcl0iz+JmuvHBACNqaggrbuSgBSmGkA2BWrLgqDN alPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aQl9dzOLW6gwgXurnGb3tJ3kjSN10KfXFeW4HLDAnSI=; b=kGgeisNfCV31GPlAxbY6G4IfZS6rIHlK5YTrW1ZMcLwR6JhzWpxxsKgG6RlwQYCefu teVVz2S2IJYB/5CyqblkEFIKe3tTYY5rLf7kYWCd0LMC65+C0UmEwwsq/F8TjH+LIMWp 8fvcybtUHrfHtABeFyop2UN5QLdL4i3XwgGTjChpbVTNB5ukMZzC+hxWPtwk06f9VYqo cDEZx9KhXDiA0vbfPsDHySaNrB/RZRcEIK5TAVgvvypMYARiBEQKyxEthUbPkhvjvvch K/j66lJPs/UPNDpnKkU5PhEkua9N6jEZg0I8KpsBhgrSD2D3AsKlTUhV2oapNmB3jKsy Ilzg== X-Gm-Message-State: AIVw113nXk/BdXFlfEkrHTzuuEJ/js6ZDTUtDcrX4vXRgMrOvbjibwBL tgXPEcRIBkSHFyu5Mg8x36J/J1D01Q== X-Received: by 10.202.77.199 with SMTP id a190mr2368072oib.196.1499830870179; Tue, 11 Jul 2017 20:41:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.162.10 with HTTP; Tue, 11 Jul 2017 20:41:09 -0700 (PDT) In-Reply-To: References: <848b3f21-9516-8a66-e4b3-9056ce38d6f6@roeck-us.net> From: Linus Torvalds Date: Tue, 11 Jul 2017 20:41:09 -0700 X-Google-Sender-Auth: QYUfke7ukUAZo0ePu-gaFT2MJek Message-ID: Subject: Re: Lots of new warnings with gcc-7.1.1 To: Guenter Roeck Cc: Tejun Heo , Jean Delvare , Bartlomiej Zolnierkiewicz , Sathya Prakash , "James E.J. Bottomley" , Greg Kroah-Hartman , "the arch/x86 maintainers" , xen-devel , linux-block , Linux Media Mailing List , IDE-ML , "linux-fbdev@vger.kernel.org" , Network Development Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds wrote: > > If that's the case, I'd prefer just turning off the format-truncation > (but not overflow) warning with '-Wno-format-trunction". Doing KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation) in the main Makefile certainly cuts down on the warnings. We still have some overflow warnings, including the crazy one where gcc doesn't see that the number of max7315 boards is very limited. But those could easily be converted to just snprintf() instead, and then the truncation warning disabling takes care of it. Maybe that's the right answer. We also have about a bazillion warning: ‘*’ in boolean context, suggest ‘&&’ instead warnings in drivers/ata/libata-core.c, all due to a single macro that uses a pattern that gcc-7.1.1 doesn't like. The warning looks a bit debatable, but I suspect the macro could easily be changed too. Tejun, would you hate just moving the "multiply by 1000" part _into_ that EZ() macro? Something like the attached (UNTESTED!) patch? Linus drivers/ata/libata-core.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 8453f9a4682f..4c7d5a138495 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3231,19 +3231,19 @@ static const struct ata_timing ata_timing[] = { }; #define ENOUGH(v, unit) (((v)-1)/(unit)+1) -#define EZ(v, unit) ((v)?ENOUGH(v, unit):0) +#define EZ(v, unit) ((v)?ENOUGH((v)*1000, unit):0) static void ata_timing_quantize(const struct ata_timing *t, struct ata_timing *q, int T, int UT) { - q->setup = EZ(t->setup * 1000, T); - q->act8b = EZ(t->act8b * 1000, T); - q->rec8b = EZ(t->rec8b * 1000, T); - q->cyc8b = EZ(t->cyc8b * 1000, T); - q->active = EZ(t->active * 1000, T); - q->recover = EZ(t->recover * 1000, T); - q->dmack_hold = EZ(t->dmack_hold * 1000, T); - q->cycle = EZ(t->cycle * 1000, T); - q->udma = EZ(t->udma * 1000, UT); + q->setup = EZ(t->setup, T); + q->act8b = EZ(t->act8b, T); + q->rec8b = EZ(t->rec8b, T); + q->cyc8b = EZ(t->cyc8b, T); + q->active = EZ(t->active, T); + q->recover = EZ(t->recover, T); + q->dmack_hold = EZ(t->dmack_hold, T); + q->cycle = EZ(t->cycle, T); + q->udma = EZ(t->udma, UT); } void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,