On 2 March 2016 at 10:16, James Greenhalgh <james.greenha...@arm.com> wrote:
> 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.
>

Indeed, I'm wondering why the testcase depends on argc beeing non-zero?

> 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.
>> >>
>>

Reply via email to