On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote: > On 1 March 2016 at 10:51, James Greenhalgh <james.greenha...@arm.com> 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 <rguent...@suse.de> > >> > > > >> > > 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. 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. > >> >
