On Tue, 1 Mar 2016, 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 <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). > > 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).
So does b = a define a macro then and the warning is to avoid you doing ldr = b ... ldr 0, 1 (or whatever correct ldr instruction) and have that ldr replaced by b? Then it's a bug to emit aliases in this form and I hope .set ldr, b doesn't have the same effect. Richard.
