From patchwork Thu Mar 3 19:57:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christophe Lyon X-Patchwork-Id: 63492 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp95005lbc; Thu, 3 Mar 2016 11:57:38 -0800 (PST) X-Received: by 10.66.251.194 with SMTP id zm2mr6322707pac.131.1457035057885; Thu, 03 Mar 2016 11:57:37 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id l73si94035pfi.113.2016.03.03.11.57.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Mar 2016 11:57:37 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-422717-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcc-patches-return-422717-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-422717-patch=linaro.org@gcc.gnu.org; dkim=pass header.i=@gcc.gnu.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=dioMdKg5H4WQr90Weg GigE4kSs7PmFdp40jbJE5WOizCFvrGHfLjE9bRt4LpMzqZUGIKjBKnlNPBaOetLp DC3Q5sBJ0m200f9dknNerMoZ9X/qQ/U2tJcUgQzqX57GhLYCvpBbQfCZbAFJMfwC 1fH0kvNjJ/ZFhR/I7P2CH2diE= 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 :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=4rdrTypF7BCTcdlOXAOHVbad a+c=; b=W+qQUieL4Wy9jJcOqmrtoyJ4QlqWrR7wARJzFkqKUX42HbQFOvCtO65M J9Zr9iqMA2GmR5DxG7CsOpNlm1sPqtRzuz7D915ZbE1Fhn/etaVTmw0isi7BaYsp C5LCfXiQ5OiD2d3dl90Cp3oJpojy7MzllzP8+ZGP7x1cmwhLn4U= Received: (qmail 21009 invoked by alias); 3 Mar 2016 19:57:22 -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 20958 invoked by uid 89); 3 Mar 2016 19:57:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=20160304, 2016-03-04, Accept, 97 X-HELO: mail-qg0-f41.google.com Received: from mail-qg0-f41.google.com (HELO mail-qg0-f41.google.com) (209.85.192.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 03 Mar 2016 19:57:19 +0000 Received: by mail-qg0-f41.google.com with SMTP id u110so26242546qge.3 for ; Thu, 03 Mar 2016 11:57:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KvUmhaeZhi7YX70GJT3t/rRTNav4VkUnwyHWxHt4SNQ=; b=nHW2Y5f/ZysOu9jDIyGt99DngqUOelf1KwIrJ1PfXtFr9hD3ypGAMXuZhHXOZN6xr4 rqdKtOfgAGD1NWzoztUE9zaDwZpnvIHK1PamzgyHSuN4jH0RF1g5OTdxwrAB1mpOqXm6 PLILag9yiM4W/DSB4rfYwky76TM/Fm2EKiorKLVUKXsTyvKzIaijc5i3/YxXKlDalgyn XmNw2ALB3ZiUOz5oHDiCudxRe7oDuJivpS+wCG/HRmxhnap8VS+6N5nZMMglo3F9MVCX vyBQjLGQNfTwECnnbZXXIUaDqaq1EGrFqiH7fP4yLZy1PqA/AXnpNHcIglL+VL9RtwNe OtTA== X-Gm-Message-State: AD7BkJJbyM04lO3sRH7SMQ24cbf3M+KglzjK1h2/AYxrVDxAp3zgGTz4kopFlsjz02ARzwdzfcSXuBcqcJ/sQQW8 MIME-Version: 1.0 X-Received: by 10.140.234.11 with SMTP id f11mr5891038qhc.51.1457035037204; Thu, 03 Mar 2016 11:57:17 -0800 (PST) Received: by 10.140.22.164 with HTTP; Thu, 3 Mar 2016 11:57:17 -0800 (PST) In-Reply-To: References: <20160229173637.GA33430@arm.com> <20160301095149.GA20934@arm.com> <20160302091556.GA34983@arm.com> Date: Thu, 3 Mar 2016 20:57:17 +0100 Message-ID: Subject: Re: [PATCH] Fix PR69951 From: Christophe Lyon To: James Greenhalgh Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Kyrylo Tkachov , Richard Earnshaw , Ramana Radhakrishnan , nick clifton X-IsSubscribed: yes On 2 March 2016 at 10:49, Christophe Lyon wrote: > On 2 March 2016 at 10:16, James Greenhalgh wrote: >> On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote: >>> On 1 March 2016 at 10:51, James Greenhalgh wrote: >>> > On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote: >>> >> On Mon, 29 Feb 2016, James Greenhalgh wrote: >>> >> >>> >> > On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard Biener wrote: >>> >> > > >>> >> > > The following fixes PR69951, hopefully the last case of decl alias >>> >> > > issues with alias analysis. This time it's points-to and the DECL_UIDs >>> >> > > used in points-to sets not being canonicalized. >>> >> > > >>> >> > > The simplest (and cheapest) fix is to make aliases refer to the >>> >> > > ultimate alias target via their DECL_PT_UID which we conveniently >>> >> > > have available. >>> >> > > >>> >> > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. >>> >> > > >>> >> > > Richard. >>> >> > > >>> >> > > 2016-02-26 Richard Biener >>> >> > > >>> >> > > PR tree-optimization/69551 >>> >> > > * tree-ssa-structalias.c (get_constraint_for_ssa_var): When >>> >> > > looking through aliases adjust DECL_PT_UID to refer to the >>> >> > > ultimate alias target. >>> >> > > >>> >> > > * gcc.dg/torture/pr69951.c: New testcase. >>> >> > >>> >> > I see this new testcase failing on an ARM target as so: >>> >> > >>> >> > /tmp/ccChjoFc.s: Assembler messages: >>> >> > /tmp/ccChjoFc.s:21: Warning: [-mwarn-syms]: Assignment makes a symbol match an ARM instruction: b >>> >> > >>> >> > FAIL: gcc.dg/torture/pr69951.c -O0 (test for excess errors) >>> >> > >>> >> > But I haven't managed to reproduce it outside of the test environment. >>> >> > >>> >> > The fix looks trivial, rename b to anything else you fancy (well... stay >>> >> > clear of add and ldr). I'll put a fix in myself if I can manage to get >>> >> > this to reproduce - though if anyone else wants to do it I won't be >>> >> > offended :-). >>> >> >>> >> Huh, I wonder what's the use of such warning. After all 'ldr' is a valid >>> >> C symbol name, too. In fact my cross arm as doesn't report this >>> >> warning (binutils 2.25.0) >>> >> >>> >> > arm-suse-linux-gnueabi-as t.s -mwarn-syms >>> >> Assembler messages: >>> >> Error: unrecognized option -mwarn-syms >>> > >>> > Right, I've figured out the set of conditions... You need to be targeting >>> > an arm-*-linux-* system to make sure that the ASM_OUTPUT_DEF definition >>> > from config/arm/linux-elf.h is pulled in. This causes us to emit: >>> > >>> > b = a >>> > >>> > Rather than >>> > >>> > .set b,a >>> > >>> > Writing it as "b = a" causes the warning added to resolve binutils >>> > PR18347 [1] to kick in, so you need binutils > 2.26 or to have backported >>> > that patch). >>> > >>> James, >>> >>> What happens for you on arm-none-eabi configurations? >>> I'm using binutils-2.25, so I can't see this warning whatever the target. >>> However, I'm using qemu-arm and this test fails on arm-none-eabi, >>> because argc is set to 0 during the startup-code. >>> >>> As I understand it, qemu-arm considers the code page as readonly, >>> and thus the GetCmdLine semi hosting call cannot write argc/argv >>> back to memory in the same code page (I'm using libgloss' crt0). >>> >>> I tried to play with qemu-system-arm, but then libgloss' crt0 does not >>> set the reset vector and the simulation does random things, starting at >>> address 0. >>> >>> Am I missing some newlib/libgloss configuration bits, or should I >>> send a newlib patch to address this? >> >> Hi Christophe, >> >> I didn't get this running under arm-none-eabi. The testcase does have >> undefined behaviour (too few arguments to main), but I'd be surprised if >> that was the issue... I'm sure the testcase could be rewritten to avoid >> the dependence on argc if this proves an issue for other bare-metal >> testers running under an emulator. >> > > Indeed, I'm wondering why the testcase depends on argc beeing non-zero? > To avoid modifying the testcase too much, I propose to replace if (argc) by if (argc >= 0) as in the attached patch. This does make the trick on arm-non-eabi. OK? Christophe. >> Thanks, >> James >> >>> > Resolving it by hacking the testcase would be one fix, but I wonder why the >>> > ARM port prefers to emit "b = a" in a linux environment if .set does the >>> > same thing and always avoids the warning? Maybe Ramana/Richard/Kyrill/Nick >>> > remember? (AArch64 does the same thing, but the AArch64 gas port doesn't >>> > have the PR18347 fix). >>> > >>> > Cheers, >>> > James >>> > >>> > --- >>> > >>> > [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=18347 >>> > >>> >> >>> >> Richard. >>> >> >>> 2016-03-04 Christophe Lyon * gcc.dg/torture/pr69951.c: Accept argc==0. diff --git a/gcc/testsuite/gcc.dg/torture/pr69951.c b/gcc/testsuite/gcc.dg/torture/pr69951.c index cb46fef..be9a027 100644 --- a/gcc/testsuite/gcc.dg/torture/pr69951.c +++ b/gcc/testsuite/gcc.dg/torture/pr69951.c @@ -9,7 +9,7 @@ extern int d __attribute__((alias("c"))); int main(int argc) { int *p, *q; - if (argc) + if (argc >= 0) p = &c, q = &d; else p = &b, q = &d;