This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- From: Julian Brown <julian at codesourcery dot com>
- To: Kyrylo Tkachov <kyrylo dot tkachov at arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Fri, 9 Aug 2013 11:01:08 +0100
- Subject: Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- References: <005101ce9445$c27e6280$477b2780$ at email@example.com>
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov <firstname.lastname@example.org> wrote:
> Hi all,
> The recently added gcc.target/arm/pr58041.c test exposed a bug in the
> backend. When compiling for NEON and with -mno-unaligned-access we
> end up generating the vld1.64 and vst1.64 instructions instead of
> doing the accesses one byte at a time like -mno-unaligned-access
> expects. This patch fixes that by enabling the NEON expander and
> insns that produce these instructions only when unaligned accesses
> are allowed.
> Bootstrapped on arm-linux-gnueabihf. Tested arm-none-eabi on qemu.
> Ok for trunk and 4.8?
I'm not sure if this is right, FWIW -- do the instructions in question
trap if the CPU is set to disallow unaligned accesses? I thought that
control bit only affected ARM core loads & stores, not NEON ones.
Not to say the test case you mention isn't broken anyway, for some
other reason -- but I don't think disabling NEON movmisalign
for !unaligned_access is the right way to fix it.