From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id BE7A8385802B for ; Mon, 11 Jan 2021 16:18:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BE7A8385802B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=danielengel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=libgcc@danielengel.com Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9435C5C01D3; Mon, 11 Jan 2021 11:18:32 -0500 (EST) Received: from imap35 ([10.202.2.85]) by compute4.internal (MEProxy); Mon, 11 Jan 2021 11:18:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielengel.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=ICeY0Emdx/HTpFMz0sD5i3eLZ24I oMi3KLYRIyr4Fq4=; b=hbZV+dtGy/RgGav3SSyYyIDPE4oasDcWxN9PuOAyFeVk i2peFWqXSInYK64VjYeh8ZoRY/QqiOKWCqAAsR/N5/DLXych8PaMXlBKppX76155 B6QRDWbeWlWyCTdNctqVk23i1w34uVvj7mb513xWfIBwp31ZvdtEXAmTq8gnzk35 +HgFxqBEAEqg9Xl4/ovcLRB93oNc4BardcvCHaw/qGPlRplaPtIWqna2NIqE9n9w 18g+9cbGftzcRmbhPHsP96KCxseOZHGex/DfZtxFpGq+aq2HqgVzDQ43pfvDdVZD 2oQtwJryKruNs28AOEuwVlie9JuP7rtfBIPoAKjXsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ICeY0E mdx/HTpFMz0sD5i3eLZ24IoMi3KLYRIyr4Fq4=; b=JHixFDHJLWTfr0p5nYIG2J 4BTxxSB6ThX8BIn5ZqPKE2ibMGLfqdqmgNPs/6+Yz8YDK5KXL/HlvDYNWngME11a M53l344hy2AzlXp0JCp4rFLItyipi2t/b6wJB9qnoJq1AI2biWmRX3avPGFgEnWN uGGo+0WKd1elZaEM5iJsfK5VJ1t6O4qete8DUEYqboCGqtDhOn9q/sByjk/yLtBu KTCenIBbvKAjYULLIupTB2cfi6UMxB1tqz1AaszGxdVPcTr0Yg9jJc+s4CiraTfE 1XOx2F4lvymz7qk1L3E99ExdTui4phChIC8tVqcygaWWlgOlLuPQalAQuFDa34DA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghn ihgvlhcugfhnghgvlhdfuceolhhisghgtggtsegurghnihgvlhgvnhhgvghlrdgtohhmqe enucggtffrrghtthgvrhhnpeelhfevveduueehiedvueeukeelgeevteehffevffegffei uedtveduveegffdvgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehlihgsghgttgesuggrnhhivghlvghnghgvlhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1023CAE0074; Mon, 11 Jan 2021 11:18:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-Id: <85294ea5-1e59-4e7c-874b-97a62dde56b5@www.fastmail.com> In-Reply-To: References: <3b36bc72-e92e-4372-8da4-43ade34d868b@www.fastmail.com> <962a0e7d-f431-42ee-aa42-e4e4cc823a10@www.fastmail.com> <35908b07-8822-e415-2abc-e04b8c9a692d@foss.arm.com> <7e0f7bb7-c2c4-4c77-8dc2-5f5c20a7bcec@www.fastmail.com> <3ba1767e-26f3-96d2-e5c7-987ca0a10f1d@foss.arm.com> <17c601ba-60e4-446c-b7b4-b1674d8500e5@www.fastmail.com> Date: Mon, 11 Jan 2021 08:18:57 -0800 From: "Daniel Engel" To: "Christophe Lyon" Cc: "Richard Earnshaw" , "gcc Patches" Subject: Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0 Content-Type: text/plain X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 16:18:34 -0000 On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote: > On Sat, 9 Jan 2021 at 14:09, Christophe Lyon wrote: > > > > On Sat, 9 Jan 2021 at 13:27, Daniel Engel wrote: > > > > > > On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote: > > > > On 07/01/2021 00:59, Daniel Engel wrote: > > > > > --snip-- > > > > > > > > > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote: > > > > > --snip-- > > > > > > > > > >> - finally, your popcount implementations have data in the code segment. > > > > >> That's going to cause problems when we have compilation options such as > > > > >> -mpure-code. > > > > > > > > > > I am just following the precedent of existing lib1funcs (e.g. __clz2si). > > > > > If this matters, you'll need to point in the right direction for the > > > > > fix. I'm not sure it does matter, since these functions are PIC anyway. > > > > > > > > That might be a bug in the clz implementations - Christophe: Any thoughts? > > > > > > __clzsi2() has test coverage in "gcc.c-torture/execute/builtin-bitops-1.c" > > Thanks, I'll have a closer look at why I didn't see problems. > > > > So, that's because the code goes to the .text section (as opposed to > .text.noread) > and does not have the PURECODE flag. The compiler takes care of this > when generating code with -mpure-code. > And the simulator does not complain because it only checks loads from > the segment with the PURECODE flag set. > This is far out of my depth, but can something like: ifeq (,$(findstring __symbian__,$(shell $(gcc_compile_bare) -dM -E - > > The 'clzs' and 'ctz' functions should never have problems. -mpure-code > > > appears to be valid only when the 'movt' instruction is available, which > > > means that the 'clz' instruction will also be available, so no array loads. > > No, -mpure-code is also supported with v6m. > > > > > Is the -mpure-code state detectable as a preprocessor flag? While > > No. > > > > > 'movw'/'movt' appears to be the canonical solution, I'm not sure it > > > should be the default just because a processor supports Thumb-2. > > > > > > Do users wanting to use -mpure-code recompile the toolchain to avoid > > > constant data in compiled C functions? I don't think this is the > > > default for the typical toolchain scripts. > > No, users of -mpure-code do not recompile the toolchain. > > > > --snip -- >