Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp267932iof; Mon, 6 Jun 2022 03:09:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9Ct2j8c7LfTcO3rrJbv/WCWDIBNiyUZUnPPIhGYV1ecQgSJQsyo/cyxt/wl7BIfRfxClq X-Received: by 2002:a65:60c7:0:b0:3fb:194f:9ccb with SMTP id r7-20020a6560c7000000b003fb194f9ccbmr20627606pgv.241.1654510151953; Mon, 06 Jun 2022 03:09:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654510151; cv=none; d=google.com; s=arc-20160816; b=uoQJksuLOZFWX5OPvNv01e5nBX0N4tt2uClCF00uqbfhlRGlUqCGicOkm42hnlxXTI 1GIAbwjAMoQuaFjFZ2E13aKxHXIPWPF+74RBzLcZ0RgwhEFapkur64E9jrDux6EDWpZn USTdAdcNA8N31Xt6eB5rrTelJO6rMp9liT9QRwYJFXI7kGMYS6BHsGAcwISfUFBePCBn 3xTVNKJ+0fWLDI0CpcjbT5hDpPwA7B3v/6BP2L1MfEaUOUE551OAXlmObR5BW8py0jAF xV/TaDfJZvDXgkf+coj92kYL9vAZRgHGo1MZ+lDkeQnFF6H6/Kw55e+GOwqPCyJgs3f/ bYYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=dHKXbrN1+fKH8ib7BNDyk2oKkNXw7BoJKlA47Wxid60=; b=Ut+348M5TyEkCjq2XuT6QWrZc05KORq5lFWKXY6Ww+uPb+hWetHw3Y98k8knsr6d/R DsQtPWem1hT7C7E3leaYQeidKYoBvv50GNsAJFaeYGkwUWDCEAUwjLEpQb/FEyrwkogY 4tg1ETLmm6nEWS4fUCL7Fg4OzuDBPlUPgnk3STZ/WEVNJIU1oZIB5mESpK/vTvpKAaFA W4BSQ+j4FYeZazlHN2FpvV62QAmxhcBvCr7uUwgai1xYP2BM4WWfSbNwbR3C0m8vpI/6 ZmPtRarrroQA4TMSO26qB1PnFESZRWldKamzhrsXSEve1hlfcK2IJF6GDXIR5357KpZd 9BNg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c12-20020a655a8c000000b003fbbafcb7ebsi19296755pgt.496.2022.06.06.03.09.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 03:09:11 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 157FDDF64; Mon, 6 Jun 2022 02:42:32 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233151AbiFFJmW (ORCPT + 99 others); Mon, 6 Jun 2022 05:42:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233184AbiFFJmG (ORCPT ); Mon, 6 Jun 2022 05:42:06 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DA7561E5636 for ; Mon, 6 Jun 2022 02:42:02 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 955B52B; Mon, 6 Jun 2022 02:42:02 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.39.103]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D1EAA3F66F; Mon, 6 Jun 2022 02:41:59 -0700 (PDT) Date: Mon, 6 Jun 2022 10:41:50 +0100 From: Mark Rutland To: Arnd Bergmann Cc: Naresh Kamboju , Linux ARM , open list , regressions@lists.linux.dev, lkft-triage@lists.linaro.org, Catalin Marinas , Will Deacon , Andrew Morton , John Donnelly , Huacai Chen , Bjorn Andersson , Andy Shevchenko , David Hildenbrand , "Guilherme G. Piccoli" , Zhen Lei , Anshuman Khandual , Kefeng Wang Subject: Re: gcc-12: build errors: arch/arm64/kernel/setup.c:225:56: warning: array subscript -1 is outside array bounds of 'char[]' [-Warray-bounds] Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 03, 2022 at 09:40:07AM +0200, Arnd Bergmann wrote: > On Fri, Jun 3, 2022 at 4:03 AM Naresh Kamboju wrote: > > inlined from 'setup_arch' at arch/arm64/kernel/setup.c:350:2: > > arch/arm64/kernel/setup.c:225:56: warning: array subscript -1 is > > outside array bounds of 'char[]' [-Warray-bounds] > > 225 | kernel_code.end = __pa_symbol(__init_begin - 1); > > > > Is this the only warning of this type that you get for arm64? There are a handful of those subscript warnings. Looking at v5.19-rc1 defconfig, using the kernel.org GCC 12.1.0 cross toolchain: | [mark@lakrids:~/src/linux]% usekorg 12.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j50 2>&1 | grep -A1 subscript | arch/arm64/kernel/setup.c:225:56: warning: array subscript -1 is outside array bounds of 'char[]' [-Warray-bounds] | 225 | kernel_code.end = __pa_symbol(__init_begin - 1); | -- | arch/arm64/kernel/setup.c:227:48: warning: array subscript -1 is outside array bounds of 'char[]' [-Warray-bounds] | 227 | kernel_data.end = __pa_symbol(_end - 1); | -- | arch/arm64/kernel/hibernate.c:94:65: warning: array subscript -1 is outside array bounds of 'const void[]' [-Warray-bounds] | 94 | unsigned long nosave_end_pfn = sym_to_pfn(&__nosave_end - 1); The last of those can't have the `- 1` pulled out, but we could stuff a RELOC_HIDE() in there, as __pa_symbol() has internally. Ideally we'd rework the section markers to not have this problem, either rethinking the way we mark them as flexible arrays, or giving them accessors, e.g. #define va_init_begin() RELOC_HIDE((unsigned long)__init_begin) ... which'd be a pain, but at least it'd solve this generally. > I think the easy fix would be to reword this line to > > kernel_code.end = __pa_symbol(__init_begin) - 1; > I agree that'd work for the __pa_symbol() cases. For consistency it might be worth using RELOC_HIDE(), e.g. kernel_code.end = __pa_symbol(RELOC_HIDE(__init_begin)) - 1); ... which IIUC should do the trick. Thanks, Mark.