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 X-Patchwork-Id: 1035252 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95925C282C3 for ; 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 ; 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 ); 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 ); Thu, 24 Jan 2019 10:44:26 -0500 Received: by mail-wm1-f68.google.com with SMTP id g67so3548002wmd.2 for ; 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 To: Krzysztof Kozlowski Cc: Laura Abbott , Herbert Xu , Ard Biesheuvel , Catalin Marinas , Martin Sebor , 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: 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 --- 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.