From patchwork Wed Jan 11 16:32:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrill Tkachov X-Patchwork-Id: 713822 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tzDw50FBJz9t1T for ; Thu, 12 Jan 2017 03:33:08 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Bj5xFJK9"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; q=dns; s=default; b=wCwdjc5o5BNOZLBvgNy5+41ymhBa4m4b3iZkdsR7Z5T +xV1SVtuHDRu6wIqohtHXgcg4PYAk+MCS//sv6EqlknjhqsuKM8vlMz70c/6qhVS DkgxGPBnLtklxFE3+wg/VVjieHIa5TyNkePZXH2VJkrQ2kvfXTdZHCsbiqlxUfr8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:content-type; s=default; bh=t6+/gBRCsm5wvniL0Wo/2EECOjo=; b=Bj5xFJK9S9qCDJoMr m5XbvtZkmx/9CxR6lfvRhEExb2XSw87jbwn7yQ5rfADDo4sRSvEb1boa/UyWwBpE SwcYzLYYcfJZT/GS1H1pbi1q7kclQ95Noyminguya/FG4Hf6D8G39/IPj7hV07ef 0jA3gEtx39DleHzizahOVh3k4Y= Received: (qmail 16809 invoked by alias); 11 Jan 2017 16:32:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 15770 invoked by uid 89); 11 Jan 2017 16:32:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, KAM_STOCKGEN, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=kyrylo, Kyrylo, U*kyrylo.tkachov X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Jan 2017 16:32:48 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8BA1AC14; Wed, 11 Jan 2017 08:32:47 -0800 (PST) Received: from [10.2.207.77] (e100706-lin.cambridge.arm.com [10.2.207.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBAEF3F242; Wed, 11 Jan 2017 08:32:46 -0800 (PST) Message-ID: <58765E2D.5030609@foss.arm.com> Date: Wed, 11 Jan 2017 16:32:45 +0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: GCC Patches CC: Richard Earnshaw , James Greenhalgh , Marcus Shawcroft Subject: [PATCH][AArch64][GCC 6] PR target/79041: Correct -mpc-relative-literal-loads logic in aarch64_classify_symbol Hi all, In this PR we generated ADRP/ADD instructions with :lo12: relocations on symbols even though -mpc-relative-literal-loads is used. This is due to the confusing double-negative logic of the nopcrelative_literal_loads aarch64 variable and its relation to the aarch64_nopcrelative_literal_loads global variable in the GCC 6 branch. Wilco fixed this on trunk as part of a larger patch (r237607) and parts of that patch were backported, but other parts weren't and that patch now doesn't apply cleanly to the branch. The actual bug here is that aarch64_classify_symbol uses nopcrelative_literal_loads instead of the correct aarch64_nopcrelative_literal_loads. nopcrelative_literal_loads gets set to 1 if the user specifies -mpc-relative-literal-loads(!) whereas aarch64_nopcrelative_literal_loads gets set to false, so that is the variable we want to check. So this is the minimal patch that fixes this. Bootstrapped and tested on aarch64-none-linux-gnu on the GCC 6 branch. Ok for the branch? Thanks, Kyrill 2017-01-11 Kyrylo Tkachov PR target/79041 * config/aarch64/aarch64.c (aarch64_classify_symbol): Use aarch64_nopcrelative_literal_loads instead of nopcrelative_literal_loads. 2017-01-11 Kyrylo Tkachov PR target/79041 * gcc.target/aarch64/pr79041.c: New test. diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 83dbd57..fa61289 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -9324,7 +9324,7 @@ aarch64_classify_symbol (rtx x, rtx offset) /* This is alright even in PIC code as the constant pool reference is always PC relative and within the same translation unit. */ - if (nopcrelative_literal_loads + if (aarch64_nopcrelative_literal_loads && CONSTANT_POOL_ADDRESS_P (x)) return SYMBOL_SMALL_ABSOLUTE; else diff --git a/gcc/testsuite/gcc.target/aarch64/pr79041.c b/gcc/testsuite/gcc.target/aarch64/pr79041.c new file mode 100644 index 0000000..a23b1ae --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/pr79041.c @@ -0,0 +1,26 @@ +/* PR target/79041. Check that we don't generate the LO12 relocations + for -mpc-relative-literal-loads. */ +/* { dg-do compile } */ +/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads" } */ + +extern int strcmp (const char *, const char *); +extern char *strcpy (char *, const char *); + +static struct +{ + char *b; + char *c; +} d[] = { + {"0", "000000000000000"}, {"1", "111111111111111"}, +}; + +void +e (const char *b, char *c) +{ + int i; + for (i = 0; i < 1; ++i) + if (!strcmp (d[i].b, b)) + strcpy (c, d[i].c); +} + +/* { dg-final { scan-assembler-not ":lo12:" } } */