From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C256C433E0 for ; Mon, 3 Aug 2020 11:09:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74CC820719 for ; Mon, 3 Aug 2020 11:09:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="ecphZuxZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726189AbgHCLJj (ORCPT ); Mon, 3 Aug 2020 07:09:39 -0400 Received: from ozlabs.org ([203.11.71.1]:37675 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725945AbgHCLJj (ORCPT ); Mon, 3 Aug 2020 07:09:39 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4BKwBn2Nw4z9s1x; Mon, 3 Aug 2020 21:09:37 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1596452977; bh=IWLgPiM5I4iS04rZIDQceT85UcRl8lxf9/puQ2anwzY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ecphZuxZTp4KL4PZQFZx3hXIVFT8iC4x4reVm8yUIMNGTiVWCDYrO5DKas7nXo/0H Q667aiyV8KzSz/LQWFHXPvblMYfNtPeWbthrpuWeGwNKtpSTCNwaRPjUdpqb1mEHmu BGECtuEciWPNEZmLJ5pK630dMEojbyIJjazZB3ql1nVudiaeLgaSAk52TpSHMFVXWx J2N0qj8rIFr/NLEj/bmHi9hGtM2nr/nlXyM+fopB7zS8Um8CG07ZGPHuv7kDaq4hRs 6ZxtpNjVGaRq/D7jN85MkDbQxm2AaI3qdmG8djKbgpgbuiLblgYmFG4lVkVG7G7RQc 5O74oR7BcTxiQ== From: Michael Ellerman To: Geert Uytterhoeven , Segher Boessenkool Cc: Nathan Chancellor , Arnd Bergmann , Geoff Levand , Linux Kernel Mailing List , clang-built-linux , Paul Mackerras , Joel Stanley , linuxppc-dev Subject: Re: [PATCH] powerpc/boot: Use address-of operator on section symbols In-Reply-To: References: <20200624035920.835571-1-natechancellor@gmail.com> <20200720210252.GO30544@gate.crashing.org> Date: Mon, 03 Aug 2020 21:09:36 +1000 Message-ID: <87zh7cyoi7.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Geert Uytterhoeven writes: > On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool > wrote: >> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote: >> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor >> > wrote: >> > > /* If we have an image attached to us, it overrides anything >> > > * supplied by the loader. */ >> > > - if (_initrd_end > _initrd_start) { >> > > + if (&_initrd_end > &_initrd_start) { >> > >> > Are you sure that fix is correct? >> > >> > extern char _initrd_start[]; >> > extern char _initrd_end[]; >> > extern char _esm_blob_start[]; >> > extern char _esm_blob_end[]; >> > >> > Of course the result of their comparison is a constant, as the addresses >> > are constant. If clangs warns about it, perhaps that warning should be moved >> > to W=1? >> > >> > But adding "&" is not correct, according to C. >> >> Why not? >> >> 6.5.3.2/3 >> The unary & operator yields the address of its operand. [...] >> Otherwise, the result is a pointer to the object or function designated >> by its operand. >> >> This is the same as using the name of an array without anything else, >> yes. It is a bit clearer if it would not be declared as array, perhaps, >> but it is correct just fine like this. > > Thanks, I stand corrected. > > Regardless, the comparison is still a comparison between two constant > addresses, so my fear is that the compiler will start generating > warnings for that in the near or distant future, making this change > futile. They're not constant at compile time though. So I don't think the compiler could (sensibly) warn about that? (surely!) cheers