Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp522867imj; Sat, 9 Feb 2019 02:44:43 -0800 (PST) X-Google-Smtp-Source: AHgI3IZrwskpMsFnuNTn4tcQPS8gh1KZSGIzhMIowyEwYVh1+13f5UAohxD+h6pOJbXwostAV6Nu X-Received: by 2002:a63:e715:: with SMTP id b21mr24854386pgi.305.1549709083802; Sat, 09 Feb 2019 02:44:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549709083; cv=none; d=google.com; s=arc-20160816; b=UK7+LEUaZPGZv/KSMQvB4984SzVsKnQwoVOtOAgMqn2iq8pCW6JI8lvbZsv7Sytl4k Vo9G0ertru6ISa4iuZ8h/wSZu9NBWLYjCkGzZd6p5oI4NQH8YS3RAdteiMUQUkiZQCR8 CbQhgG9v6H9y0yA7Gl8QfF+WYO1NDFQZjv6cwwxjRjxEwTjnOlVClmxK+XPbSXFVlA9c L4NuUEAGe4T++Y6Hqo5nJAC8wd/u2T/yi0hc4ejgmO4mViWBTQB8v95HTp11fxAX/JJA Qv7+lw6l1aorCOI8XvTnLjnUJBsLTOLXWl5lTS0FkO0YaXVDd+UpB0ExatVAytDYF6/l 58nw== 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=W0dpvtJ7/qEb3l3RkpI4dGKSw3NkP3w0C4upGTOHmio=; b=lObeCpxGm9FOHvMJVyxQY9tJyf9oMFzaaWxi6K04xA0E8nx7nyCasppgI0e3Pu24zo 9FFFTcOHNqQXoM/GAUxNSLMKGl8l+p0V07S2Ni6XGJr+4UqZrWNyn8CO0fQh2KA/0/tx /W8C7b3AAr9Xl0V+p7+purQmdBQMl4XmP2GMzQwH4xJqw6WDnMkZFwqtuyjuMMnvU03e qZgn6/MZhehmEUja68RN07+Tm6PICqxjWk8novIHQPwFHnOgBKgXkLQzvK+ICs+lBp1G dLWbdPmaikunCckYvQIn1fmkonblPIv8qy/sZSkoTVxjd8gFiSoMM7XqzgBWKGqTm8QM dzdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TzuGmrrj; 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 t10si5052384pfi.75.2019.02.09.02.44.26; Sat, 09 Feb 2019 02:44:43 -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=TzuGmrrj; 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 S1726894AbfBIKoX (ORCPT + 99 others); Sat, 9 Feb 2019 05:44:23 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:40270 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726722AbfBIKoW (ORCPT ); Sat, 9 Feb 2019 05:44:22 -0500 Received: by mail-it1-f194.google.com with SMTP id h193so15416886ita.5 for ; Sat, 09 Feb 2019 02:44:21 -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=W0dpvtJ7/qEb3l3RkpI4dGKSw3NkP3w0C4upGTOHmio=; b=TzuGmrrjRUO+HY6aPxntPtkG3ZJdYA/0UpVLmKfg2ON0ztMVMYht1B1tCaZ1jBF4Ug kM59Yrx4vNbF6vct6zfckF+XqOTNFjlA8UfU/eiovLW3Ys3q8kel3IP6DwnmIx5mSjD+ Ao8Ku24KJcCgDwSbGJdFp+JSuv4wps6/ULMUuUG3rE9P9zOjNYLPZfT1tiSSzMm06yAi m2wrT8ijBBsYxNn4HD0k8UeEsXnDqKAljVr8Ss00Az0p+gXO3uaOP7bD/lD/3azohcgx EQZkOOzezTg5AVMYzQFcOFOaE7oZsxLyATGAl7bELfxoq5fyBggE+hm/W4muw5Z7FysJ d5pg== 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=W0dpvtJ7/qEb3l3RkpI4dGKSw3NkP3w0C4upGTOHmio=; b=DmH/FfKAlbDWhKinvv+fbW2wj2DQrTy1RWjytk6llKsSTwZpQJmXkop6MYKTuVIMNN UjSgN8M/uxXs1srTvTIga3TTR1Un5EWpzGK8lToEqe7RxqVq2z7XLncIbVjlWGzXRStP KzvqZXcrsoSNx4YLzEOgGpeckpNjzJi0n4B9k84vX9m9EMQMkXFI9Tf0Ma6jS39LDB0J uONeCMLclkx0ecr9vzdpy2N6DLWbDovUH9NgHkpErgaIqlkTlaVxAU59YGqvcDJtxgW/ mCzbAMMn875cCofhuTOdPjacEmZ2PwRalrVv73JpSWi2GtDnFpF1RKoFOwTzLj0KkhkV WwGg== X-Gm-Message-State: AHQUAuad2A5foYovgu2/YN+JL14zDfxbR08Otc241FUhfvaq11aKWccq bvINno4cPAYSnEk0itJh+a6tN5k4Rmw9VYgODJN2kA== X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr1619174itk.71.1549709061226; Sat, 09 Feb 2019 02:44:21 -0800 (PST) MIME-Version: 1.0 References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> In-Reply-To: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> From: Ard Biesheuvel Date: Sat, 9 Feb 2019 11:44:09 +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 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. Permitting a function pointer to point to 'cold' functions only if it is annotated as 'cold' itself makes no sense whatsoever, and there could be valid cases where a function pointer may point at either cold or non-cold functions. For other attributes, the situation is clearly different, e.g., a __pure function pointer to a non-pure function is obviously a bug, since the compiler could make assumptions based on the function pointer type that do not hold for the function it points to at runtime. I don't see how the 'cold' attribute could have any such effect, so I wonder if it isn't simply a bug that we have to report to GCC? > void __alias("f") g(void); > > diagnoses: > > warning: 'g' specifies less restrictive attribute than > its target 'f': 'cold' [-Wmissing-attributes] > > These patch series clean these new warnings. Most of them are caused > by the module_init/exit macros. > > The first patch has been in -next for a long time already, and an alternative > solution (only __cold) for module.h as well. However, since we decided > to go with the new __copy attribute, I will leave the series for a few days > again and send the PR for -rc7. > > Link: https://lore.kernel.org/lkml/20190125104353.2791-1-labbott@redhat.com/ > > Miguel Ojeda (3): > lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as __pure > Compiler Attributes: add support for __copy (gcc >= 9) > include/linux/module.h: copy __init/__exit attrs to > init/cleanup_module > > include/linux/compiler_attributes.h | 14 ++++++++++++++ > include/linux/module.h | 4 ++-- > lib/crc32.c | 4 ++-- > 3 files changed, 18 insertions(+), 4 deletions(-) > > -- > 2.17.1 >