From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106540 invoked by alias); 24 Feb 2020 11:05:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 106525 invoked by uid 89); 24 Feb 2020 11:05:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=efforts X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Feb 2020 11:05:35 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 05A21ABD7 for ; Mon, 24 Feb 2020 11:05:32 +0000 (UTC) Date: Mon, 24 Feb 2020 11:05:00 -0000 From: Petr Tesarik To: gcc@gcc.gnu.org Subject: Branch instructions that depend on target distance Message-ID: <20200224120528.0a88c6a8@ezekiel.suse.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_//nnwZxD5dLNYZhMTsNW5Cmt"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00179.txt.bz2 --Sig_//nnwZxD5dLNYZhMTsNW5Cmt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 1763 Hi all, I'm looking into reviving the efforts to port gcc to VideoCore IV [1]. One issue I've run into is the need to find out target branch distance at compile time. I looked around, and it's not the first one architecture with such requirement, but AFAICS it has never been solved properly. For example, AVR tracks instruction length. Later, ret_cond_branch() selects between a branch instruction and an inverted branch followed by an unconditional jump based on these calculated lengths. This works great ... until there's some inline asm() statement, for which gcc cannot keep track of the length attribute, so it is probably taken as zero. Linker then fails with a cryptic message: > relocation truncated to fit: R_AVR_7_PCREL against `no symbol' I can provide a minimal test case and report a bug if you want... Developers work around the issue by rewriting their code when they are bitten by this, but it is less than optimal, because you cannot really get rid of all inline assembly, and it's in general unpredictable where these inline asm() blocks will be placed by the compiler. OTOH, the avr backend is pretty outdated, so there may be a better alternative that I'm just not seeing. Any hints? Background: There is a port of the VC4 port of the LK embedded kernel [2]. I have tried to build that kernel with optimization turned on, but I'm getting: compiling kernel/thread.c /tmp/ccJFdnfX.s: Assembler messages: /tmp/ccJFdnfX.s:1451: Error: operand out of range (64 not between -64 and 6= 3) That's because there is an inline "di" (disable interrupts) instruction inside a conditional statement in thread_yield(), which causes this off-by-one miscalculation. Petr T [1] https://github.com/itszor/gcc-vc4 [2] https://github.com/librerpi/lk --Sig_//nnwZxD5dLNYZhMTsNW5Cmt Content-Type: application/pgp-signature Content-Description: Digitální podpis OpenPGP Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEHl2YIZkIo5VO2MxYqlA7ya4PR6cFAl5TrfgACgkQqlA7ya4P R6eYbwgAkdO7fXkoGxCflnqs7sg/zCzbXUtwUwoYSmgDXd0T/z9We6L93JbJfyB1 4UcArn6NsYdGPK8SsZTyJWeZf8Y/bUxmZOH06S5S2ju6Lq/Vek4OJEURUy5KMGbK nXQ3eKp8ookcCyMoZt2OojMIcaHDemsTPrJYwaA87kaqX0IQeDVmRmTmq3xNc4Hy GJKYrI42MC7DcFyi/3qXM5JU64UD5h2DYfVOAIhOrauJcquboQBGS4tcu3hmzttg PvVRnLAMlFZh50nN2pxR51VSUTrPv0HG+GjQ3CvYnNFvpYNv1RXAtGaT1gPf/9LV drDHASmjrSRUZEAg6u878bt1716JRw== =8ekj -----END PGP SIGNATURE----- --Sig_//nnwZxD5dLNYZhMTsNW5Cmt--