[Bug target/61551] [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}

2020-09-22 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from cbaylis at gcc dot gnu.org ---

This was fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=612ea540d2e1fe5eae5213823a3cec0d3d864fb2

 This patch adds support for modelling the varying costs of different
addressing modes.

This patch adds support for modelling the varying costs of
different addressing modes. The generic cost table treats
all addressing modes as having equal cost.

gcc/ChangeLog:

2017-11-23  Charles Baylis  

* config/arm/arm-protos.h (enum arm_addr_mode_op): New.
(struct addr_mode_cost_table): New.
(struct tune_params): Add field addr_mode_costs.
* config/arm/arm.c (generic_addr_mode_costs): New.
(arm_slowmul_tune): Initialise addr_mode_costs field.
(arm_fastmul_tune): Likewise.
(arm_strongarm_tune): Likewise.
(arm_xscale_tune): Likewise.
(arm_9e_tune): Likewise.
(arm_marvell_pj4_tune): Likewise.
(arm_v6t2_tune): Likewise.
(arm_cortex_tune): Likewise.
(arm_cortex_a8_tune): Likewise.
(arm_cortex_a7_tune): Likewise.
(arm_cortex_a15_tune): Likewise.
(arm_cortex_a35_tune): Likewise.
(arm_cortex_a53_tune): Likewise.
(arm_cortex_a57_tune): Likewise.
(arm_exynosm1_tune): Likewise.
(arm_xgene1_tune): Likewise.
(arm_cortex_a5_tune): Likewise.
(arm_cortex_a9_tune): Likewise.
(arm_cortex_a12_tune): Likewise.
(arm_cortex_a73_tune): Likewise.
(arm_v7m_tune): Likewise.
(arm_cortex_m7_tune): Likewise.
(arm_v6m_tune): Likewise.
(arm_fa726te_tune): Likewise.
(arm_mem_costs): Use table lookup to calculate cost of addressing
mode.

From-SVN: r255112

[Bug lto/95846] Combination of LTO and -Wl, --defsym causes symbol to be resolved as NULL

2020-06-23 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95846

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Reported to binutils bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=26163

[Bug lto/95846] New: Combination of LTO and -Wl,--defsym causes symbol to be resolved as NULL

2020-06-23 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95846

Bug ID: 95846
   Summary: Combination of LTO and -Wl,--defsym causes symbol to
be resolved as NULL
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following program demonstrates this problem:

==< test1.c >==
#include 

void f(void);
void g(void);

void f(void)
{
  printf("in f()\n");
  g();
  printf("back in f()\n");
}
==< test2.c >==
#include 

void f(void);

void real_g(void)
{
printf("in real_g()\n");
}

int main()
{
real_g();
f();
}
== end ==

$ gcc -Os -c test1.c
$ gcc -O2 -flto -c test2.c
$ gcc -O2 test1.o test2.o -o test -Wl,--defsym,g=real_g
$ ./test
in real_g()
in f()
Segmentation fault (core dumped)

The segfault is caused because there is no real_g symbol and g has been
resolved to NULL.

00401146 :
  401146:   50  push   %rax
  401147:   bf 15 20 40 00  mov$0x402015,%edi
  40114c:   e8 df fe ff ff  callq  401030 
  401151:   e8 aa ee bf ff  callq  0 < oops!
  401156:   bf 10 20 40 00  mov$0x402010,%edi
  40115b:   5a  pop%rdx
  40115c:   e9 cf fe ff ff  jmpq   401030 
  401161:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  401168:   00 00 00 
  40116b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

Seen on Fedora 32 (gcc 10.1.1, binutils 2.34) and Ubuntu 18.04 (gcc 7.5.0,
binutils 2.30)

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

2016-03-24 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #3 from cbaylis at gcc dot gnu.org ---
new patch posted to mailing list

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01403.html

[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A

2016-03-15 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from cbaylis at gcc dot gnu.org ---

I managed to look into this in more detail with a colleague. The segfault
happens because the implementation of __tls_get_addr in glibc returns an
invalid pointer. This seems to be a problem with static linking only, and
dynamic linking will avoid the problem.

A slightly simplified test case (without the exception handling) is:

#include 
#include 

__thread int __attribute__ ((tls_model ("global-dynamic"))) x = 10;

class Thread {
  public:
void operator()(){
  fprintf(stderr, "testing (%i) ...\n", x);
}
};

int main(void){
  Thread t;
  std::thread th(std::ref(t));
  th.join();
  return 0;
}


If you install a copy of jessie filesystem somewhere on your build machine, you
should be able to compile and link against the libraries on that version using
--sysroot=/path/to/fs. This should allow you to create dynamically linked
binaries which work on your target

I've created a glibc bug for this
https://sourceware.org/bugzilla/show_bug.cgi?id=19826.

Since I don't think this is a bug in gcc, I'll close this bug.

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

2016-02-12 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00881.html

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

2016-02-11 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm*-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-11
   Assignee|unassigned at gcc dot gnu.org  |cbaylis at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from cbaylis at gcc dot gnu.org ---
I will post a patch to the list shortly

[Bug target/69770] New: [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

2016-02-11 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770

Bug ID: 69770
   Summary: [ARM] -mlong-calls does not affect calls to
__gnu_mcount_nc generated by -pg
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
  Target Milestone: ---

When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc function
are not generated as long calls.

extern void g(void);
int f() { g(); return 0; }

compiles to:

push{r4, lr}
push{lr}
bl  __gnu_mcount_nc;// not a long call
ldr r3, .L2
blx r3 ;// a long call to g()
mov r0, #0
pop {r4, pc}

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2016-02-09 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from cbaylis at gcc dot gnu.org ---
Fixed by these patches

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00630.html
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00632.html

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2016-02-09 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

--- Comment #4 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Tue Feb  9 18:49:05 2016
New Revision: 233252

URL: https://gcc.gnu.org/viewcvs?rev=233252&root=gcc&view=rev
Log:
[ARM] PR68532 Fix up vzip recognition for big endian

gcc/ChangeLog:

2016-02-09  Charles Baylis  

PR target/68532
* config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane
order.
* config/arm/arm_neon.h (vzipq_s8): Adjust shuffle patterns for big
endian.
(vzipq_s16): Likewise.
(vzipq_s32): Likewise.
(vzipq_f32): Likewise.
(vzipq_u8): Likewise.
(vzipq_u16): Likewise.
(vzipq_u32): Likewise.
(vzipq_p8): Likewise.
(vzipq_p16): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2016-02-09 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

--- Comment #3 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Tue Feb  9 18:47:55 2016
New Revision: 233251

URL: https://gcc.gnu.org/viewcvs?rev=233251&root=gcc&view=rev
Log:
[ARM] PR68532: Fix up vuzp for big endian

gcc/ChangeLog:

2016-02-09  Charles Baylis  

   PR target/68532
   * config/arm/arm.c (neon_endian_lane_map): New function.
   (neon_vector_pair_endian_lane_map): New function.
   (arm_evpc_neon_vuzp): Allow for big endian lane order.
   * config/arm/arm_neon.h (vuzpq_s8): Adjust shuffle patterns for big
   endian.
   (vuzpq_s16): Likewise.
   (vuzpq_s32): Likewise.
   (vuzpq_f32): Likewise.
   (vuzpq_u8): Likewise.
   (vuzpq_u16): Likewise.
   (vuzpq_u32): Likewise.
   (vuzpq_p8): Likewise.
   (vuzpq_p16): Likewise.

gcc/testsuite/ChangeLog:
2016-02-09  Charles Baylis  

   PR target/68532
   * gcc.c-torture/execute/pr68532.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68532.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h
trunk/gcc/testsuite/ChangeLog

[Bug target/63304] Aarch64 pc-relative load offset out of range

2016-01-21 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #42 from cbaylis at gcc dot gnu.org ---

While we're suggesting fixes to the kernel, wouldn't it be better if
CONFIG_ARM64_ERRATUM_843419 forced the kernel to be built with the linker
workarounds if the kernel is configured

KBUILD_LDFLAGS += --fix-cortex-a53-843419
or maybe
KBUILD_LDFLAGS += $(call ld-option, --fix-cortex-a53-843419)

[Bug target/63304] Aarch64 pc-relative load offset out of range

2016-01-21 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cbaylis at gcc dot gnu.org

--- Comment #40 from cbaylis at gcc dot gnu.org ---
The kernel does support a mechanism to add a command line option for only
compilers which support it.

Documentation/kbuild/makefiles.txt:
cc-option
cc-option is used to check if $(CC) supports a given option, and if
not supported to use an optional second option.

I think you could therefore add this line to arch/arm64/Makefile
KBUILD_CFLAGS   += $(call cc-option,-mpc-relative-literal-loads)

[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A

2016-01-12 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-12
 CC||cbaylis at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Also happens on trunk.

I'm taking a look at this

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2015-12-16 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01644.html

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-11-30 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from cbaylis at gcc dot gnu.org ---
Now fixed on trunk, for both ARM and AArch64 targets.

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-11-30 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #14 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Nov 30 17:11:16 2015
New Revision: 231077

URL: https://gcc.gnu.org/viewcvs?rev=231077&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2015-11-30  Charles Baylis  

PR target/63870
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f16_indices_1.c
(f_vld2_lane_f16): Remove xfails for arm targets.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c
(f_vld2_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c
(f_vld2_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_p8_indices_1.c
(f_vld2_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s16_indices_1.c
(f_vld2_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s32_indices_1.c
(f_vld2_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s64_indices_1.c
(f_vld2_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s8_indices_1.c
(f_vld2_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u16_indices_1.c
(f_vld2_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u32_indices_1.c
(f_vld2_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u64_indices_1.c
(f_vld2_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u8_indices_1.c
(f_vld2_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f16_indices_1.c
(f_vld2q_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f32_indices_1.c
(f_vld2q_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f64_indices_1.c
(f_vld2q_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_p8_indices_1.c
(f_vld2q_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s16_indices_1.c
(f_vld2q_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s32_indices_1.c
(f_vld2q_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s64_indices_1.c
(f_vld2q_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s8_indices_1.c
(f_vld2q_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u16_indices_1.c
(f_vld2q_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u32_indices_1.c
(f_vld2q_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u64_indices_1.c
(f_vld2q_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u8_indices_1.c
(f_vld2q_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f16_indices_1.c
(f_vld3_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f32_indices_1.c
(f_vld3_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f64_indices_1.c
(f_vld3_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_p8_indices_1.c
(f_vld3_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s16_indices_1.c
(f_vld3_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s32_indices_1.c
(f_vld3_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s64_indices_1.c
(f_vld3_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s8_indices_1.c
(f_vld3_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u16_indices_1.c
(f_vld3_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u32_indices_1.c
(f_vld3_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u64_indices_1.c
(f_vld3_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u8_indices_1.c
(f_vld3_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f16_indices_1.c
(f_vld3q_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f32_indices_1.c
(f_vld3q_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f64_indices_1.c
(f_vld3q_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_p8_indices_1.c
(f_vld3q_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s16_indices_1.c
(f_vld3q_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s32_indices_1.c
(f_vld3q_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s64_indices_1.c
(f_vld3q_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s8_indices_1.c
(f_vld3q_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u16_indices_1.c
(f_vld3q_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u32_indices_1.c
(f_vld3q_lane_u32): Ditto.
* gcc.target

[Bug target/68532] [ARM] Incorrect code result on arm big endian

2015-11-25 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-25
 CC||cbaylis at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |cbaylis at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from cbaylis at gcc dot gnu.org ---

This is a simplified test case, which shows the incorrect way elements are
being read from the vector loads done in the vectorized loop.

#include 
#include 

#define SIZE 128
unsigned short alignas(16) in[SIZE];
unsigned short alignas(16) out[SIZE];

__attribute__ ((noinline)) void
test (unsigned short *restrict out, unsigned short *restrict in)
{
int i;
for (int j = 0; j < SIZE; j+=8)
  out[i++] = in[j];
}

int main()
{
for (int i = 0; i   :  0   1   2   3   4   5   6   7
:  8   9   10  11  12  13  14 15
:  16  17  18  19  20  21  22 23
:  24  25  26  27  28  29  30 31

layout of q8 after vld1.64 {d16-d17}, [r1:64] (showing architectural lanes 0 to
7, in ascending order)
q8 = { 3, 2, 1, 0, 7, 6, 5, 4 }

So, the first 64 bits are loaded into lanes 0-3, but in big endian order, and
the 2nd 64 bits are loaded into lanes 4-7, also in big endian order.

The vectorizer expects that the result of loading a 128-bit vector into memory,
should be:
q8 = { 7, 6, 5, 4, 3, 2, 1, 0 }
but the back end does not do that, in an attempt to support the EABI memory
ordering for 128 bit vectors. The behaviour of 128-bit vector loads/stores is
defined by output_move_neon(). There is a large comment in arm.c above
output_move_neon ("WARNING: The ordering of elements is weird in big-endian
mode...") which explains this.

The ARM back-end already uses a strategy of representing lane numbers in a "GCC
numbering", and transforming them to architectural numbering when generating
assembly. This is currently a simple reversal in big-endian mode, and a 1:1 map
in little endian.

I think this bug could be fixed by using a mapping lane numbers so that the
behaviour of output_move_neon() is taken into account. This would prevent the
vectorizer from using VUZP for the VEC_PERM_EXPR() in big-endian mode, because
the lanes specified would not match the behaviour of VUZP on 128 bit vectors.

[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-11-16 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from cbaylis at gcc dot gnu.org ---
Closed as this is now fixed on trunk and in gcc-5-branch

[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-11-16 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

--- Comment #8 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Nov 16 15:01:01 2015
New Revision: 230427

URL: https://gcc.gnu.org/viewcvs?rev=230427&root=gcc&view=rev
Log:

backport of fix for PR67280 (r227407)

2015-11-16  Charles Baylis  

Backport from mainline r227407
PR ipa/67280
* cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external
in new callgraph edge.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cgraphunit.c

[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-11-16 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

--- Comment #7 from cbaylis at gcc dot gnu.org ---
I am backporting the fix to GCC 5 now. I'll close it once committed.

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-11-10 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #13 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:11:20 2015
New Revision: 230144

URL: https://gcc.gnu.org/viewcvs?rev=230144&root=gcc&view=rev
Log:
[ARM] PR63870 Remove error for invalid lane numbers

2015-11-11  Charles Baylis  

PR target/63870
* config/arm/neon.md (neon_vld1_lane): Remove error for invalid
lane number.
(neon_vst1_lane): Likewise.
(neon_vld2_lane): Likewise.
(neon_vst2_lane): Likewise.
(neon_vld3_lane): Likewise.
(neon_vst3_lane): Likewise.
(neon_vld4_lane): Likewise.
(neon_vst4_lane): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-11-10 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #12 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:08:43 2015
New Revision: 230143

URL: https://gcc.gnu.org/viewcvs?rev=230143&root=gcc&view=rev
Log:
[ARM] PR63870 Mark lane indices of vldN/vstN with appropriate qualifier

2015-11-11  Charles Baylis  

PR target/63870
* config/arm/arm-builtins.c: (arm_load1_qualifiers) Use
qualifier_struct_load_store_lane_index.
(arm_storestruct_lane_qualifiers) Likewise.
* config/arm/neon.md: (neon_vld1_lane) Reverse lane numbers for
big-endian.
(neon_vst1_lane) Likewise.
(neon_vld2_lane) Likewise.
(neon_vst2_lane) Likewise.
(neon_vld3_lane) Likewise.
(neon_vst3_lane) Likewise.
(neon_vld4_lane) Likewise.
(neon_vst4_lane) Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/neon.md

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-11-10 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #11 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:05:16 2015
New Revision: 230142

URL: https://gcc.gnu.org/viewcvs?rev=230142&root=gcc&view=rev
Log:
[ARM] PR63870 Add qualifiers for NEON builtins

2015-11-11  Charles Baylis  

PR target/63870
* config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator
qualifier_struct_load_store_lane_index.
(builtin_arg): New enumerator NEON_ARG_STRUCT_LOAD_STORE_LANE_INDEX.
(arm_expand_neon_args): New parameter. Remove ellipsis. Handle NEON
argument qualifiers.
(arm_expand_neon_builtin): Handle new NEON argument qualifier.
* config/arm/arm.h (NEON_ENDIAN_LANE_N): New macro.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h

[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-09-08 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

--- Comment #5 from cbaylis at gcc dot gnu.org ---
Committed to trunk http://gcc.gnu.org/r227407 and gcc/ChangeLog corrected in
http://gcc.gnu.org/r227534

[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-08-28 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

--- Comment #3 from cbaylis at gcc dot gnu.org ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01791.html

[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-08-28 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

--- Comment #2 from cbaylis at gcc dot gnu.org ---

Minimum optimisations to reproduce this are -O1 -fipa-icf-functions -fipa-sra.
These options also allow the bug to be reproduced on trunk (with -O2 the bug is
latent, I haven't investigated why).

The analysis here also uses -fno-inline, because the wrapper function is more
clearly visible. The problem occurs with and without inlining.

The failure is caused because the function:
   std::_Function_handler::_M_invoke(std::_Any_data const&)
is compiled to:

_ZNSt17_Function_handlerIFvvEZ4mainEUlvE_E9_M_invokeERKSt9_Any_data:
.fnstart
.LFB2010:
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, lr}
bl 
_ZNSt17_Function_handlerIFvvEZ4mainEUlvE0_E9_M_invokeERKSt9_Any_data
.cantunwind
.fnend

This includes .cantunwind which is an ARM-specific directive which causes the
exception unwinder to stop at this function which causes execution to
terminate.

Going further back, the ARM backend emits this directive because the function
is marked "nothrow" in the ipa-pure-const phase. This is visible in the dump:
foo.cc.062i.pure-const:Function found to be nothrow: static void
std::_Function_handler::_M_invoke(const
std::_Any_data&, _ArgTypes&& ...) [with _Functor = main()::;
_ArgTypes = {}]

This is clearly wrong, because this function calls the lambda, which contains a
throw. This happens on all targets, but does not seem to cause problems on
non-ARM targets because they use the standard/generic unwinder mechanism.

The _ZNSt17_Function_handlerIFvvEZ4mainEUlvE_E9_M_invokeERKSt9_Any_data is a
wrapper, created by cgraph_node::create_wrapper(). When this function updates
the callgraph and creates the edge to the target function, it unconditionally
sets ->can_throw_external to false, which causes the ipa-pure-const phase to
mark the wrapper function as nothrow.

I will send a patch to the mailing list shortly.

[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

2015-08-20 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-20
 CC||cbaylis at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |cbaylis at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from cbaylis at gcc dot gnu.org ---
I will have a look at this.

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-07-22 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #9 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Jul 22 10:44:16 2015
New Revision: 226059

URL: https://gcc.gnu.org/viewcvs?rev=226059&root=gcc&view=rev
Log:
gcc/ChangeLog:

2015-07-22  Charles Baylis  

PR target/63870
* config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers):
Add qualifier_struct_load_store_lane_index.
(aarch64_types_loadstruct_lane_qualifiers): Use
qualifier_struct_load_store_lane_index for lane index argument for
last argument.
(aarch64_types_storestruct_lane_qualifiers): Ditto.
(builtin_simd_arg): Add SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX.
(aarch64_simd_expand_args): Add new argument describing mode of
builtin. Check lane bounds for arguments with
SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX.
(aarch64_simd_expand_builtin): Emit error for incorrect lane indices
if marked with SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX.
(aarch64_simd_expand_builtin): Handle arguments with
qualifier_struct_load_store_lane_index. Pass machine mode of builtin to
aarch64_simd_expand_args.
* config/aarch64/aarch64-simd-builtins.def: Declare ld[234]_lane and
vst[234]_lane with BUILTIN_VALLDIF.
* config/aarch64/aarch64-simd.md:
(aarch64_vec_load_lanesoi_lane): Use VALLDIF iterator. Perform
endianness reversal on lane index.
(aarch64_vec_load_lanesci_lane): Ditto.
(aarch64_vec_load_lanesxi_lane): Ditto.
(vec_store_lanesoi_lane): Use VALLDIF iterator.
(vec_store_lanesci_lane): Ditto.
(vec_store_lanesxi_lane): Ditto.
(aarch64_ld2_lane): Use VALLDIF iterator. Remove endianness
reversal of lane index.
(aarch64_ld3_lane): Ditto.
(aarch64_ld4_lane): Ditto.
(aarch64_st2_lane): Ditto.
(aarch64_st3_lane): Ditto.
(aarch64_st4_lane): Ditto.
* config/aarch64/arm_neon.h (__LD2_LANE_FUNC): Rename mode parameter
to qmode. Add new mode parameter. Update uses.
(__LD3_LANE_FUNC): Ditto.
(__LD4_LANE_FUNC): Ditto.
(__ST2_LANE_FUNC): Ditto.
(__ST3_LANE_FUNC): Ditto.
(__ST4_LANE_FUNC): Ditto.

gcc/testsuite/ChangeLog:

2015-07-22  Charles Baylis  

* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_p8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s16_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u16_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_p8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s16_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u16_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f64_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_p8_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s16_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s32_indices_1.c: New
test.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s64_indices_1.c: New
test.
* gcc.target/aarch64

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-06-11 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #8 from cbaylis at gcc dot gnu.org ---
Patch posted to the mailing list

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00799.html

[Bug rtl-optimization/65304] [4.9] [ARM] incorrect "asm operand has impossible constraints" error

2015-03-03 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65304

--- Comment #1 from cbaylis at gcc dot gnu.org ---
Created attachment 34941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34941&action=edit
automatically reduced test case

[Bug rtl-optimization/65304] New: [4.9] [ARM] incorrect "asm operand has impossible constraints" error

2015-03-03 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65304

Bug ID: 65304
   Summary: [4.9] [ARM] incorrect "asm operand has impossible
constraints" error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
Target: arm-unknown-linux-gnueabihf

Created attachment 34940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34940&action=edit
Original test case

The attached test case, and reduced variant result in an error: "asm operand
has impossible constraints". This is a regression since 4.8.

$ arm-unknown-linux-gnueabihf-gcc -O2 -S orig.c -mbig-endian -mthumb
-march=armv7-a -mtune=cortex-a8
orig.c: In function ‘rpc_print_iostats’:
orig.c:169:4: error: ‘asm’ operand has impossible constraints
asm ( "umlal %R0, %Q0, %R2, %Q3\n\t"  \
^
orig.c:215:2: note: in expansion of macro ‘do_div’
  do_div(t, 100);
  ^
-
or

$ arm-unknown-linux-gnueabihf-gcc -O2 -S reduced.c -mbig-endian -mthumb
-march=armv7-a -mtune=cortex-a8
reduced.c: In function ‘fn2’:
reduced.c:26:7: error: ‘asm’ operand has impossible constraints
   asm("@asm2 %R0 %Q0 %R1 %R2 %Q2 %R3 %Q3" : "+&r"(n), "+&r"(q) :
"r"(o), "r"(p));
   ^


This does not occur on trunk, due to commit r209615:
2014-04-22  Ramana Radhakrishnan  

   * config/arm/arm.c (arm_hard_regno_mode_ok): Loosen
   restrictions on core registers for DImode values in Thumb2.

However, since similar restrictions still exist in ARM state, it is possible
that there remains a latent bug on trunk.

This bug was originally reported in Linaro bugzilla
https://bugs.linaro.org/show_bug.cgi?id=1199

[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.

2015-02-19 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||cbaylis at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from cbaylis at gcc dot gnu.org ---
This appears to have been fixed by r161920

2010-07-07  Bernd Schmidt  

PR rtl-optimization/44404
* auto-inc-dec.c (find_inc): Avoid calling count_occurrences if
possible, use reg_overlap_mentioned_p instead.

*** This bug has been marked as a duplicate of bug 44404 ***

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

2015-02-19 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gilles.chanteperdrix@xenoma
   ||i.org

--- Comment #9 from cbaylis at gcc dot gnu.org ---
*** Bug 38674 has been marked as a duplicate of this bug. ***

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-01-14 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #6 from cbaylis at gcc dot gnu.org ---
There is still a lot to do. I have patches in progress for Aarch64 loads and
stores. Aarch64 shifts still need doing, and everything for ARM.

[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2

2014-11-27 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||cbaylis at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #7 from cbaylis at gcc dot gnu.org ---

This is caused by an invalid implementation of memset in (old versions of) the
Linux kernel.

I investigated this, a longer description is on the Linaro bugzilla at
https://bugs.linaro.org/show_bug.cgi?id=928#c7

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2014-11-20 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu Nov 20 16:26:54 2014
New Revision: 217885

URL: https://gcc.gnu.org/viewcvs?rev=217885&root=gcc&view=rev
Log:
PR target/63870
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
expression to aarch64_simd_lane_bounds.
* config/aarch64/aarch64-protos.h (aarch64_simd_lane_bounds): Update
prototype.
* config/aarch64/aarch64-simd.md: (aarch64_combinez): Update
call to aarch64_simd_lane_bounds.
(aarch64_get_lanedi): Likewise.
(aarch64_ld2_lane): Likewise.
(aarch64_ld3_lane): Likewise.
(aarch64_ld4_lane): Likewise.
(aarch64_im_lane_boundsi): Likewise.
* config/aarch64/aarch64.c (aarch64_simd_lane_bounds): Add exp
parameter. Report calling function in error message if exp is non-NULL.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-builtins.c
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64-simd.md
trunk/gcc/config/aarch64/aarch64.c

[Bug target/63870] New: [Aarch64] [ARM] Errors in use of NEON instrinsics are reported incorrectly

2014-11-14 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

Bug ID: 63870
   Summary: [Aarch64] [ARM] Errors in use of NEON instrinsics are
reported incorrectly
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: cbaylis at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
CC: alan.lawrence at arm dot com
Target: arm-unknown-linux-gnueabi, aarch64-linux-gnu

Created attachment 33972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33972&action=edit
Example tests

Several NEON intrinsics have arguments which must be a constant integer in a
fixed range. At present, these constraints are enforced for most intrinsics
during assembly output, or, in some cases, not checked at all.

This can be fixed by using the %K format specifier to the error message. See 
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01248.html for a proposed patch
and explanation.

Once that patch is applied, it is necessary to rework the expansion of the
builtins so that the constraints are checked during expansion. Some of this
work has been started for Aarch64
(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00421.html)


Example demonstration of incorrect error messages using attached test cases on
an ARM target. Note that the error message is reported at the end of each
function, rather than the line where the error occurs.

$ arm-unknown-linux-gnueabihf-gcc -c neon_const_range_tests/* -mfpu=neon
neon_const_range_tests/vld1.c: In function ‘f_vld1_lane’:
neon_const_range_tests/vld1.c:10:1: error: lane out of range
 }
 ^
neon_const_range_tests/vld4.c: In function ‘f_vld4_lane’:
neon_const_range_tests/vld4.c:10:1: error: lane out of range
 }
 ^
neon_const_range_tests/vmul_lane.c: In function ‘f_vmul_lane’:
neon_const_range_tests/vmul_lane.c:10:1: error: lane out of range
 }
 ^
neon_const_range_tests/vshl.c: In function ‘f_vshl’:
neon_const_range_tests/vshl.c:10:1: error: constant out of range
 }
 ^
neon_const_range_tests/vshrn_n.c: In function ‘f_vshrn_n’:
neon_const_range_tests/vshrn_n.c:10:1: error: constant out of range
 }
 ^
neon_const_range_tests/vst1.c: In function ‘f_vst1_lane’:
neon_const_range_tests/vst1.c:9:1: error: lane out of range
 }
 ^
neon_const_range_tests/vst4.c: In function ‘f_vst4_lane’:
neon_const_range_tests/vst4.c:9:1: error: lane out of range
 }
 ^

[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix

2014-09-29 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #35 from cbaylis at gcc dot gnu.org ---

Backports committed to 4.8 and 4.9

[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix

2014-09-29 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

--- Comment #34 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 17:07:47 2014
New Revision: 215686

URL: https://gcc.gnu.org/viewcvs?rev=215686&root=gcc&view=rev
Log:
2014-09-29  Charles Baylis  

Backport from mainline r212303
PR target/49423
* config/arm/arm-protos.h (arm_legitimate_address_p,
arm_is_constant_pool_ref): Add prototypes.
* config/arm/arm.c (arm_legitimate_address_p): Remove static.
(arm_is_constant_pool_ref) New function.
* config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
(arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
operand and remove pool_range and neg_pool_range attributes.
(arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
pool_range and neg_pool_range attributes.
* config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow
constant pool references.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/arm-protos.h
branches/gcc-4_8-branch/gcc/config/arm/arm.c
branches/gcc-4_8-branch/gcc/config/arm/arm.md
branches/gcc-4_8-branch/gcc/config/arm/constraints.md

[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix

2014-09-29 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

--- Comment #33 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 16:47:31 2014
New Revision: 215685

URL: https://gcc.gnu.org/viewcvs?rev=215685&root=gcc&view=rev
Log:
2014-09-29  Charles Baylis  

Backport from mainline r212303
PR target/49423
* config/arm/arm-protos.h (arm_legitimate_address_p,
arm_is_constant_pool_ref): Add prototypes.
* config/arm/arm.c (arm_legitimate_address_p): Remove static.
(arm_is_constant_pool_ref) New function.
* config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
(arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
operand and remove pool_range and neg_pool_range attributes.
(arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
pool_range and neg_pool_range attributes.
* config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow
constant pool references.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm-protos.h
branches/gcc-4_9-branch/gcc/config/arm/arm.c
branches/gcc-4_9-branch/gcc/config/arm/arm.md
branches/gcc-4_9-branch/gcc/config/arm/constraints.md

[Bug target/63277] ARM - NEON excessive use of vmov for vtbl2 / uint8x8x2 for shuffling data unnecessarily around

2014-09-17 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63277

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cbaylis at gcc dot gnu.org

--- Comment #4 from cbaylis at gcc dot gnu.org ---
A much simplified test case based on arm_neon_excessive_vmov_wo_vcombine.c 

$ arm-unknown-linux-gnueabihf-gcc -O2 -S -o - -mfpu=neon mini.c 

#include 

void f(int8_t *p)
{
   int8x16_t v;
   int8x8_t v2;
   int8x8x2_t vx;

   v=vld1q_s8(p);
   v2=vld1_s8(p);
   vx.val[0] = vget_low_s8(v);
   vx.val[1] = vget_high_s8(v);
   v2 = vtbl2_s8(vx, v2);
   vst1_s8(p, v2);
}

With -dp, the generated code is:
f:
vld1.8  {d18-d19}, [r0] @ 6 neon_vld1v16qi  [length = 4]
vmovd16, d18  @ v8qi@ 10*neon_movv8qi/1 [length = 4]
vld1.8  {d20}, [r0] @ 7 neon_vld1v8qi   [length = 4]
vmovd17, d19  @ v8qi@ 11*neon_movv8qi/1 [length = 4]
vtbl.8  d16, {d16, d17}, d20@ 12neon_vtbl2v8qi  [length = 4]
vst1.8  {d16}, [r0] @ 13neon_vst1v8qi   [length = 4]
bx  lr  @ 24*thumb2_return  [length = 4]

By the time IRA runs, the insns which result in the moves look like this:
(insn 9 18 11 2 (set (subreg:V8QI (reg/v:TI 116 [ vx ]) 0)
(subreg:V8QI (reg:V16QI 114 [ D.14019 ]) 0)) /tmp/mini.c:11 827
{*neon_movv8qi}

The registers 116 and 114 are allocated to different hard registers, as they
conflict. Presumably, the register allocator could be taught to treat this
subreg->subreg move as a copy and allow the same hard register to be allocated.

[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

2014-08-04 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

--- Comment #6 from cbaylis at gcc dot gnu.org ---

git bisect points to r211625 as the revision which fixes/hides this bug on
trunk.

2014-06-13  Richard Biener  

* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
Rewrite to propagate the VN result into all uses where
possible and to remove stmts becoming dead because of that.
(eliminate): Generalize stmt removal handling, remove in
reverse dominator order to support proper debug stmt
generation.  Update stmts before removing stmts.
* tree-ssa-propagate.c (propagate_tree_value): Remove
bogus assert.

[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

2014-08-04 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cbaylis at gcc dot gnu.org

--- Comment #5 from cbaylis at gcc dot gnu.org ---
Created attachment 33244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33244&action=edit
Reduced test case


$ arm-unknown-linux-gnueabihf-gcc -S -O2 -g reduced1.cpp

[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-08-04 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from cbaylis at gcc dot gnu.org ---
Fixed in r213376

Mailing list thread: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02009.html

[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-07-31 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu Jul 31 14:27:58 2014
New Revision: 213376

URL: https://gcc.gnu.org/viewcvs?rev=213376&root=gcc&view=rev
Log:
PR target/61948

gcc/ChangeLog:
2014-07-29  Charles Baylis  

PR target/61948
* config/arm/neon.md (ashldi3_neon): Don't emit arm_ashldi3_1bit unless
constraints are satisfied.
(di3_neon): Likewise.

gcc/testsuite/ChangeLog:
2014-07-29  Charles Baylis  

PR target/61948
* gcc.target/arm/pr61948.c: New test case.



Added:
trunk/gcc/testsuite/gcc.target/arm/pr61948.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
trunk/gcc/testsuite/ChangeLog

[Bug target/61948] [ARM] [4.9 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-07-29 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-07-29
 Ever confirmed|0   |1

[Bug target/61948] New: [ARM] [4.9 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)

2014-07-29 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948

Bug ID: 61948
   Summary: [ARM] [4.9 regression] ICE with DImode shift by 1 bit
(in copyprop_hardreg_forward_1)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: cbaylis at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
Target: arm-unknown-linux-gnueabihf

Created attachment 33202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33202&action=edit
Original test case, needs -std=c++11

Originally reported at:
https://bugs.linaro.org/show_bug.cgi?id=176

The lshrdi3_neon,ashrdi3_neon,ashldi3_neon patterns can call
gen_arm_di3_1bit without checking that the register allocation
constraints of the resulting insn are satisfied. This results in an ICE:

Simplified test case:
--<
long long f (long long *c)
{
  long long t = c[0];
  /* force t into [r1,r2] */
  asm ("nop" : : : "r0", "r3", "r4", "r5",
   "r6", "r7", "r8", "r9",
   "r10", "r11", "r12", "memory");
  return t >> 1;
}
===>---

$ arm-unknown-linux-gnueabihf-gcc -O2 -mfpu=neon -mthumb -c t.c
t.c: In function ‘f’:
t.c:8:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 18 7 14 2 (parallel [
(set (reg/i:DI 0 r0)
(ashiftrt:DI (reg/v:DI 1 r1 [orig:110 t ] [110])
(const_int 1 [0x1])))
(clobber (reg:CC 100 cc))
]) t.c:8 131 {arm_ashrdi3_1bit}
 (expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
t.c:8:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775

[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix

2014-07-09 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||cbaylis at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |cbaylis at gcc dot 
gnu.org

--- Comment #31 from cbaylis at gcc dot gnu.org ---
I intend to backport to 4.8 and 4.9, once this change has had a week of testing
on trunk.

[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix

2014-07-05 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

--- Comment #29 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Sat Jul  5 11:58:06 2014
New Revision: 212303

URL: https://gcc.gnu.org/viewcvs?rev=212303&root=gcc&view=rev
Log:
[ARM] PR target/49423

2014-07-05  Charles Baylis  

PR target/49423
* config/arm/arm-protos.h (arm_legitimate_address_p,
arm_is_constant_pool_ref): Add prototypes.
* config/arm/arm.c (arm_legitimate_address_p): Remove static.
(arm_is_constant_pool_ref) New function.
* config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
(arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
operand. Remove pool_range and neg_pool_range attributes.
(arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
pool_range and neg_pool_range attributes.
* config/arm/constraints.md (Uh): New constraint.
(Uq): Don't allow constant pool references.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/constraints.md

[Bug target/61551] New: [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}

2014-06-18 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551

Bug ID: 61551
   Summary: [NEON] alter costs to allow use of post-indexed
addressing modes for VLD{2..4}/VST{2..4}
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com
Target: arm-unknown-linux-gnueabi

Created attachment 32967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32967&action=edit
test for NEON addressing modes

The attached test case demonstrates that GCC does not exploit the post-indexed
addressing mode for NEON structure loads and stores: VLDn, VSTn where n>=2.

Generated code for VLD1/VST1 (using desired post-indexed addressing)

test_ld1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld1.8  {d16}, [r0], r1
vst1.8  {d16}, [r0], r1
vld1.8  {d16}, [r0], r1
vst1.8  {d16}, [r0], r1
vld1.8  {d16}, [r0], r1
vst1.8  {d16}, [r0]
bx  lr

Generated code for VLD2:
test_ld2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
addsr3, r0, r1
vld2.8  {d16-d17}, [r0]
addsr0, r3, r1
addsr2, r0, r1
vst2.8  {d16-d17}, [r3]
addsr3, r2, r1
vld2.8  {d16-d17}, [r0]
add r1, r1, r3
vst2.8  {d16-d17}, [r2]
vld2.8  {d16-d17}, [r3]
vst2.8  {d16-d17}, [r1]
bx  lr


A proof of concept patch is posted at:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01361.html

[Bug target/61411] New: [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411

2014-06-04 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411

Bug ID: 61411
   Summary: [NEON] ICE in reload_cse_simplify_operands, at
postreload.c:411
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbaylis at gcc dot gnu.org
Target: aarch64-oe-linux

Created attachment 32890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32890&action=edit
Reduced test case

The attached test case results in an ICE when compiled with gcc 4.9

$ aarch64-oe-linux-gcc -O3 -c test.c
test.c: In function ‘vp9_idct16x16_256_add_neon_pass2’:
test.c:126:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 198 110 159 2 (set (reg:V8QI 37 v5 [orig:118 D.16400 ] [118])
(mem:V8QI (plus:DI (reg/v/f:DI 20 x20 [orig:202 dest ] [202])
(reg:DI 8 x8 [340])) [2 MEM[(const int64_t *)dest_44]+0 S8
A64]))
/home/cbaylis/tools/tools-aarch64-oe-linux-4.9/lib/gcc/aarch64-oe-linux/4.9.1/include/arm_neon.h:3646
735 {*aarch64_simd_movv8qi}
 (nil))
test.c:126:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:411
0x7fc47a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/rtl-error.c:109
0x7fc49f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/rtl-error.c:120
0x7bdbd9 reload_cse_simplify_operands
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:411
0x7bf69c reload_cse_simplify
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:181
0x7bf69c reload_cse_regs_1
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:220
0x7bfa8b reload_cse_regs
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:68
0x7bfa8b rest_of_handle_postreload
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:2332
0x7bfa8b execute
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:2368


There is a patch which appears to fix this problem at
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02397.html

[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242

2014-05-19 Thread cbaylis at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||cbaylis at gcc dot gnu.org
  Known to work||4.8.3
 Resolution|--- |FIXED

--- Comment #10 from cbaylis at gcc dot gnu.org ---
Now also fixed on 4.7 and 4.8 branches.

[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242

2014-05-08 Thread cbaylis at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

--- Comment #9 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu May  8 17:06:04 2014
New Revision: 210227

URL: http://gcc.gnu.org/viewcvs?rev=210227&root=gcc&view=rev
Log:
2014-05-08  Charles Baylis  

Backport from mainline
2014-04-07  Charles Baylis  

PR target/60609
* config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove.
(LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after
ADDR_DIFF_VEC.


Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr60609.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/arm/arm.h

[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242

2014-05-08 Thread cbaylis at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

--- Comment #8 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu May  8 17:06:01 2014
New Revision: 210226

URL: http://gcc.gnu.org/viewcvs?rev=210226&root=gcc&view=rev
Log:
2014-05-08  Charles Baylis  

Backport from mainline
2014-04-07  Charles Baylis  

PR target/60609
* config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove.
(LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after
ADDR_DIFF_VEC.


Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr60609.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/arm.h

--- Comment #9 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu May  8 17:06:04 2014
New Revision: 210227

URL: http://gcc.gnu.org/viewcvs?rev=210227&root=gcc&view=rev
Log:
2014-05-08  Charles Baylis  

Backport from mainline
2014-04-07  Charles Baylis  

PR target/60609
* config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove.
(LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after
ADDR_DIFF_VEC.


Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr60609.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/arm/arm.h

[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242

2014-05-08 Thread cbaylis at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

--- Comment #8 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Thu May  8 17:06:01 2014
New Revision: 210226

URL: http://gcc.gnu.org/viewcvs?rev=210226&root=gcc&view=rev
Log:
2014-05-08  Charles Baylis  

Backport from mainline
2014-04-07  Charles Baylis  

PR target/60609
* config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove.
(LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after
ADDR_DIFF_VEC.


Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr60609.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/arm.h