From patchwork Thu Jan 24 15:44:20 2019
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
X-Patchwork-Id: 1035252
Return-Path: <SRS0=jJS3=QA=vger.kernel.org=linux-kernel-owner@kernel.org>
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id 95925C282C3
for <linux-kernel@archiver.kernel.org>; Thu, 24 Jan 2019 15:44:28 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
by mail.kernel.org (Postfix) with ESMTP id 6368521872
for <linux-kernel@archiver.kernel.org>; Thu, 24 Jan 2019 15:44:28 +0000 (UTC)
Authentication-Results: mail.kernel.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.b="DEOxuN9k"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1728590AbfAXPo1 (ORCPT
<rfc822;linux-kernel@archiver.kernel.org>);
Thu, 24 Jan 2019 10:44:27 -0500
Received: from mail-wm1-f68.google.com ([209.85.128.68]:37788 "EHLO
mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1727649AbfAXPo0 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Thu, 24 Jan 2019 10:44:26 -0500
Received: by mail-wm1-f68.google.com with SMTP id g67so3548002wmd.2
for <linux-kernel@vger.kernel.org>;
Thu, 24 Jan 2019 07:44:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=date:from:to:cc:subject:message-id:mime-version:content-disposition
:user-agent;
bh=JeyLhzrsCRzzO/4nbb0LJSQxILVpgC++VcQqugacalc=;
b=DEOxuN9kV3A3qQ3ere0UjnfgT3DE1Gc4z/52Qty46F/mbpPja2OkXvtPJ15RK9/h4Z
AG1fdkKf/GjCRaBidO9BLWwcoq0uiTV69J0KR0rF67QR9zxgGVEl8fu6s/ZmtKnnIdF4
AysPfOHY+/MwlcB6UOzADtS69SDUYTsxDxOfHBj/FjnS7WmNetq8ae17VvRdpd/JEWtE
M58OhgBYmckFYuVXQTEEhpm8w6TIefPA5S3r3KeUuXclMeqJ07pU1vJWK7tdTp7sIeAv
xYgGq49/NBPkUl4l+LdwVBwp+o6pvUfh2w9zBQW67xZu6rn/j500BV8xdubxQqHTauSM
oQPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
:content-disposition:user-agent;
bh=JeyLhzrsCRzzO/4nbb0LJSQxILVpgC++VcQqugacalc=;
b=twekOdboep908h8e5de5qIQIgDuUrOYeS/p8s5bh3AYpMD9r3CIJtanHSCWnFCsPIw
/hesYDvbpVSiQTI1afBap2tw2ugq2aL2Sur2/9BhWE5So2HlVMlN5M6S8ccs6IK6Ldzh
+wxWJnq7dnvwbpMLcT3mASpdlEUPTaVTA7AazIssYrIDY9ucJA4vfYUemvvTtKn2tovO
lJjVDsOwv7/3P9XphLneTUXTI1ZD9soUX/qpt1m4n4BAme1tHfmbAL4cceRfMf7eFKhh
t3iRpkh/6ZHMGw0moeXPkTB+WTDhA7MgsmQA/X6tmPfjfMQsEo+OKRUBtFuuVDY5wzSf
eX7Q==
X-Gm-Message-State: AJcUukcM8ZahlKLufK0H1V2XtT0GIN899FyU1V2PJM0+/GfK3XvzMW2n
o0kPoin07YrKIK/Zh71qAxI=
X-Google-Smtp-Source:
ALg8bN7upuyKWCD/cTB9FAkdcEyU6dlTStUcg49cEAv640NugO83fRipoQ9X2YGpIogSFxA7BbHmeQ==
X-Received: by 2002:a1c:bbd6:: with SMTP id l205mr2979576wmf.97.1548344665032;
Thu, 24 Jan 2019 07:44:25 -0800 (PST)
Received: from gmail.com (79.108.96.12.dyn.user.ono.com. [79.108.96.12])
by smtp.gmail.com with ESMTPSA id
k128sm80898610wmd.37.2019.01.24.07.44.23
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 24 Jan 2019 07:44:24 -0800 (PST)
Date: Thu, 24 Jan 2019 16:44:20 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Laura Abbott <labbott@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Martin Sebor <msebor@gcc.gnu.org>, linux-kernel@vger.kernel.org
Subject: [PATCH] lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as
__pure
Message-ID: <20190124154420.GA11471@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: elm/2
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
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.
In particular, it triggers here because crc32_le_base/__crc32c_le_base
aren't __pure while their target crc32_le/__crc32c_le are.
These aliases are used by architectures as a fallback in accelerated
versions of CRC32. See commit 9784d82db3eb ("lib/crc32: make core crc32()
routines weak so they can be overridden").
Therefore, being fallbacks, it is likely that even if the aliases
were called from C, there wouldn't be any optimizations possible.
Currently, the only user is arm64, which calls this from asm.
Still, marking the aliases as __pure makes sense and is a good idea
for documentation purposes and possible future optimizations,
which also silences the warning.
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
I am picking this up through the compiler-attributes tree
and putting it into -next along with the other cleanup
for -Wmissing-attributes (unless some other maintainer wants it).
lib/crc32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/crc32.c b/lib/crc32.c
index 45b1d67a1767..4a20455d1f61 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -206,8 +206,8 @@ u32 __pure __weak __crc32c_le(u32 crc, unsigned char const *p, size_t len)
EXPORT_SYMBOL(crc32_le);
EXPORT_SYMBOL(__crc32c_le);
-u32 crc32_le_base(u32, unsigned char const *, size_t) __alias(crc32_le);
-u32 __crc32c_le_base(u32, unsigned char const *, size_t) __alias(__crc32c_le);
+u32 __pure crc32_le_base(u32, unsigned char const *, size_t) __alias(crc32_le);
+u32 __pure __crc32c_le_base(u32, unsigned char const *, size_t) __alias(__crc32c_le);
/*
* This multiplies the polynomials x and y modulo the given modulus.