Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp557901imj; Sat, 9 Feb 2019 03:27:34 -0800 (PST) X-Google-Smtp-Source: AHgI3IbDYcY55n8aSkPGAJhwPxzo89vgap5rcRWZwd7sUnVIkKfD8cZhizTEyWspXStbqNMLaN3f X-Received: by 2002:a63:f91c:: with SMTP id h28mr663035pgi.14.1549711654436; Sat, 09 Feb 2019 03:27:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549711654; cv=none; d=google.com; s=arc-20160816; b=KPPF6AOIYnbGjfqi1II4ZX4cp6XJtJojkrDQnGO3SgG+fZXQD24t1ghIHtqTbjtBJg V2+facbpAj4q2nPVRAxkmBQPM7c6FXh7jynTt59eEoccWoJ/bYwE/0xbIGQhJr5HJhso HjCa/zNITc3ad28YxCt18KMe8yaoiGjFjAU4H0rgBM/TCTiJgXkx1rdjUaFHZIHdO5eP 2CpEFTaM+N5+xX9r/gd6SNxmq1G0RNCGSPvYWJQxrisaZy490NhjmutYoBN9YxGJWvQE /IZv6u2JtPmhE/+eWb22AC5nAI1oIpIcNYNne9TWt73dMDFPLr3lTnvS4zGPve4V1ZCc eWfQ== 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=7q6z+34+FnKC4hX+HhfniurjW/0RmyWhUrpxIJ3+8VQ=; b=pZqSVb/R2GzHVgTauVAL9oEcd1wyBLtYUEvYtDKo0Hix3vs24dpzK4G3QOYSbdzS0a CPRlqz59i+EuW2imAuEmpmMwEqhIS/OpNvZO3NQSLQJN8r6DRPYWDjFzaZOZl6NjJedu JD6aaWlW2aRat3OpUq7MuYIRQl+wL0X+gWWcNHybDWfIp9o0/0xTTqWAr7qXb4CnTMh/ bqvyYVq8N993Aqnja0YaLVzhsEjosZit3qolIBQspovlvP3+eobRtXvaujVtCUhNPtpG NlJbX1uu1Zq9DmxdN2mxXAWAXMDZaJF5lbIayi9CvaaID/YZ/KIuWoDDQeQOA7adadLL Vx8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=SRpt93ly; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m6si4712128pll.86.2019.02.09.03.27.17; Sat, 09 Feb 2019 03:27:34 -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=@linaro.org header.s=google header.b=SRpt93ly; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727002AbfBIL0X (ORCPT + 99 others); Sat, 9 Feb 2019 06:26:23 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:54109 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726821AbfBIL0X (ORCPT ); Sat, 9 Feb 2019 06:26:23 -0500 Received: by mail-it1-f194.google.com with SMTP id g85so15408793ita.3 for ; Sat, 09 Feb 2019 03:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7q6z+34+FnKC4hX+HhfniurjW/0RmyWhUrpxIJ3+8VQ=; b=SRpt93lyJbIljyFa750SX3DwDGQNoCErXgEv9DwQTa4yDWoTflhICfd7CGjeFm6Q9S ky6hMIIIwbXycp0fZ6z9578H/VD78Zdv0G8Q1pP1thNkB9KZBgvkK6QFzI9PMXBTQ4k+ cOyoDckZP8h09s3qdZVQ7/k+Mldi7Cz6CZDp3q9nOsP+DW/iikTX8KqN3AxgFGT3ZkhC R9RWGz3ShJqyCH6SN7wjgKBbo5B14hBhcTOgC/9w/4UWxJ1YsjLhqCi6MaG6d7XuQb98 0Ci1q22479Y80G4wvmozyZJ22zhHTeBZs1F/6Dn9FZ65Qn0QXl9hFSko3LA4apbCPK7F LMnQ== 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=7q6z+34+FnKC4hX+HhfniurjW/0RmyWhUrpxIJ3+8VQ=; b=Xzu3HzLq6/rmgBp9/EB2QAKgmiaxXUyWKSQjBDM94kEPsVEc90ni7gno/YwDyXFlyn tKJ8BZzvAcjhgTZwHQo/92Kon7pqOS5mGTJ2y9DzChF8AnutatK+vLB5PVW9w7ktiJoW 71d2nRNf6lfvsXwe3stuF2VcQu6HIleP/JDtbY0H3pxQyGGke+WZbSzw+fS3cSlfU62L htK1uNWQQuKh6EhK6rdvSvXeaGd90M/b7UbBBrNrwIX6RDuWEWZYhyFj6fCFn+ddKTof LJozhoO5skjp8lgR6KIIL3k5ichEEDbkGLAcoAvwYK8thZWBzZcZHlm37lUcqT2Ud959 qR+A== X-Gm-Message-State: AHQUAuZYpuBa/nJ5l/w5WuDB5yBA/epMfJ7C93qvJRxBTF2rpRTwK8bD eQGX7nzlWPHouLvBX5cR2CS7fx7wI5wtCWLG4DbDbw== X-Received: by 2002:a24:4582:: with SMTP id c2mr1814271itd.158.1549711581881; Sat, 09 Feb 2019 03:26:21 -0800 (PST) MIME-Version: 1.0 References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> In-Reply-To: From: Ard Biesheuvel Date: Sat, 9 Feb 2019 12:25:42 +0100 Message-ID: Subject: Re: [PATCH 0/3] Clean the new GCC 9 -Wmissing-attributes warnings To: Miguel Ojeda 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, 9 Feb 2019 at 12:19, Miguel Ojeda wrote: > > On Sat, Feb 9, 2019 at 11:44 AM Ard Biesheuvel > wrote: > > > > On Sat, 9 Feb 2019 at 01:09, Miguel Ojeda > > wrote: > > > > > > The upcoming GCC 9 release extends the -Wmissing-attributes warnings > > > (enabled by -Wall) to C and aliases: it warns when particular function > > > attributes are missing in the aliases but not in their target, e.g.: > > > > > > void __cold f(void) {} > > > > Apologies if I missed any discussions on this topic, but I would argue > > that 'cold' is not an attribute that has to be applied to the function > > pointer as well as each of its targets, since it basically decides the > > placement in the binary, and it doesn't affect the nature of the code > > being referenced. > > 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. So to me, it makes perfect sense to permit 'cold' on the target, but not on the function pointer itself, in which case you get 1) but not 2) > 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. > 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.