Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp611499imj; Sat, 9 Feb 2019 04:32:39 -0800 (PST) X-Google-Smtp-Source: AHgI3IbkKA7A4ZmL+p62rTwSUmayHw9IUCC0r0Fzr+ro/daVG/rEqDCDhtLSePixNSrsCN1xgxdy X-Received: by 2002:a62:ed0f:: with SMTP id u15mr26940383pfh.188.1549715559067; Sat, 09 Feb 2019 04:32:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549715559; cv=none; d=google.com; s=arc-20160816; b=BM5CsZNypAapS3b1lWHEargQaDl/2+sfREkzJOl//zH7Zx7Y6i8ZWp3KzbYg5QM0yn hkJ5XTdsCU7Vis1EALmyv+fUZapAvkGqeJ++FfepkoX8nn+r2t27QljZF4oUcGjGiLFe helhbzrEilqVPQMEWTr9bdUI5vLwFOLGgUrD5MV2CL2D5pfWZMk2HiGG+9eDa/n9G/em DbgL98lznIcgTaJHaWfUkrLcrazauMSIrSvHBeNL599xHNR9aDkTbApaj1elmRArW3iJ hK9fxHTGv49yi6BjSFWHhzVV4iriRq6S+I1YI6/D5PqDWTwrTezK32kPnBuFLGZNvmXu ma1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KcHsUnh5QxvsPy/ZT8tglv4I/mDQW8SZPvAeIODUNDw=; b=BcMwQ/cXtDsBp4/EiYyYzrB0MxKVui423HFRY/W2pJfb7rhPUJehlDdDci9edzlS5P tx0RyWEKlOGfFL6vhJS79QNv9d2XEpaymr3/03xmc1V5Asoffmo2gr6mEfU5XEcWEf8O u17tkuZjvL93EUZr+H4A4hWacxn/TGLvDXRq5Ezuy7VdD7k5hDF9kNFQAIyTtNdqRMnA qCdg268+O9Eh3Jkand6I78choV4VTC+nUoUqAjCGebmz06ErtA3ISuUMSXSY9NnxvhNp jdWnSVF4O6A0yDHHCBy5xvyYCWcD1tUqPGVJkthVmup01DZNANCHAv8aiNFEmneqHbBJ QTFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dATwHBHs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s73si4926262pfs.54.2019.02.09.04.32.23; Sat, 09 Feb 2019 04:32:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dATwHBHs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727002AbfBIMbv (ORCPT + 99 others); Sat, 9 Feb 2019 07:31:51 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:41659 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726704AbfBIMbv (ORCPT ); Sat, 9 Feb 2019 07:31:51 -0500 Received: by mail-lj1-f195.google.com with SMTP id f21-v6so3774915ljj.8 for ; Sat, 09 Feb 2019 04:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KcHsUnh5QxvsPy/ZT8tglv4I/mDQW8SZPvAeIODUNDw=; b=dATwHBHsqOkTw+3DssemY1J/e1evWXIBxi5qj4Kxdgw0zelGSpd98RYuOdpvJ+aHo3 sOy6WkG3IFSNA3p+J8ekHjBA8E5QeD/yNvfVVeS5cBeU3tzNpeh1scYJHKo0rNftUEhl RXLkVj0e0IZKE7PldQU1y41Yx7idPfTFoOTvfoncGdT4rRNYU21juaUfl/MDzfrQsDYz ZFRpsb9pax/RQD5VT1GRkhGuqToUbNOEZm8GvQjGVxXjiuuNOU0UrFVuGl67EupmkVZx LGpmlaqL5AyZp323vHN44q1sBv/BH3+lCpvPktoqkuqJw5K81eUrE3Lxhvx8xI+3tIwG 64zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KcHsUnh5QxvsPy/ZT8tglv4I/mDQW8SZPvAeIODUNDw=; b=H6eWVg618wItQcPLnwz8n+4opoI67xoRu+F+N7E1dgG4kFY79Cgea5ZQubXCSv/XtD YYhon9z7UM+emllGnv9q0X3gRERLS5qYvZ6fJOpnZLZtmrCttYlbMcMyLw9DWO+6i2w0 fqizcLJFlzm9xFCLuE3/z1KU7R7yQ3qUqp9OzY/UkHLO9zQNgf667V6MWobmgEVBn4uL 7RYujJyDE3215a3UIJaC2Ed1xHOV93ORF/cfCVgKa/SwVfNjLDFcipRbvwN0q65A9gfY XpqJbZtXpzhzD724QuoGHctaHPjF0tBYrYUnx1IP/jPls1eg768gxi15F20awZsfuSP9 el7Q== X-Gm-Message-State: AHQUAubONwNvRQ1yFMbD/xqj/KTfrs7OnFB22qhhP/rk8k2jwtn+4wUO mUvuFlBv3/+phBF4VtZJAfbmh7WxbMmDhD8p71k= X-Received: by 2002:a2e:890b:: with SMTP id d11-v6mr17821221lji.113.1549715509070; Sat, 09 Feb 2019 04:31:49 -0800 (PST) MIME-Version: 1.0 References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> In-Reply-To: From: Miguel Ojeda Date: Sat, 9 Feb 2019 13:31:38 +0100 Message-ID: Subject: Re: [PATCH 0/3] Clean the new GCC 9 -Wmissing-attributes warnings To: Ard Biesheuvel Cc: Linux Kernel Mailing List , Laura Abbott , Arnd Bergmann , Martin Sebor , Herbert Xu , Krzysztof Kozlowski , Catalin Marinas , Nick Desaulniers , Luc Van Oostenryck , Andrey Konovalov , Kees Cook , Sean Christopherson , Jessica Yu , Masahiro Yamada , James Morris , Mathieu Desnoyers , Borislav Petkov , Matt Mullins , Vincent Whitchurch , WANG Chao Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 9, 2019 at 12:26 PM Ard Biesheuvel wrote: > > On Sat, 9 Feb 2019 at 12:19, Miguel Ojeda > wrote: > > > > It also affects the optimizer in two different ways AFAIK: > > > > * For the function itself, it gets optimized for size instead of speed. > > * For callers, the paths that lead to the calls are treated as unlikely. > > > > That seems reasonable, but that still does not mean it is necessarily > a problem if you apply 'cold' to one but not the other. Indeed. As I said, it is likely that you missed the attribute, not a sure thing (i.e. that you didn't do it explicitly). > > So GCC reports it because you would be (likely) missing the > > optimizations you expected if you are using the alias instead of the > > target. > > > > I see how that could be reasonable for extern declarations that do not > match the definition, since in that case, it is assumed that there is > only one instance of the function. For function pointers, I don't > think this assumption is valid. It sounds reasonable to have another warning for declarations-definition attribute mismatches too. However, I don't see why you would warn differently. Even if you have one instance of the function, you may also be using the declaration to explicitly avoid the unlikely treatment. Now, whether the warning is worth or not or at which "level", it depends. I guess the rationale behind having it under -Wall is that they expect people to have missed copying the attributes, rather than they are using aliases specifically to avoid a cold/... attribute. > > In our case in patch 3, we do not want the optimization for callers, > > which is why we don't mark the extern declaration as __cold (see the > > commit message). > > > > You did not cc me on the whole set, so I don't have the patch. But in > any case, GCC 9 has not been released so we should still have time to > talk sense into the GCC guys. I only CC'd people on the relevant patches according to get_maintainers (but yeah, 2 & 3 are related, I could have merged those lists). Anyway, using the lore.kernel.org server makes it easy to see an entire series when you have already one: https://lore.kernel.org/lkml/20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com/ As for GCC, Martin (the author of the features) is CC'd, so he can chime in (and I am sure he appreciates the feedback :-) Cheers, Miguel