[Bug target/82150] Produces a branch prefetch which causes a hang

2017-09-19 Thread mgretton at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

mgretton at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mgretton at gcc dot gnu.org

--- Comment #4 from mgretton at gcc dot gnu.org ---
As you suggest in your original comment this hang could be coming from the
instruction pre-fetch going to some place in memory that is mapped (and
executable) but the memory system is not giving a response to memory accesses
to that location.

As a general point all read sensitive devices must be marked as XN to prevent
speculative corruption of those read sensitive devices by instruction fetch
(this is true on future versions of the architecture as well).

Can you ensure that the XN-bit is set on memory pages mapped to read-sensitive
devices?

(XN description ARM11 MP Core TRM:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0360f/CACHFICI.html)

[Bug target/59695] bad code generation on aarch64 in aarch64_output_mi_thunk

2014-01-09 Thread mgretton at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59695

mgretton at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mgretton at gcc dot gnu.org

--- Comment #1 from mgretton at gcc dot gnu.org ---
I think the actual issue is with the code in aarch64_build_constant:

  /* zcount contains the number of additional MOVK instructions
 required if the constant is built up with an initial MOVZ instruction,
 while ncount is the number of MOVK instructions required if starting
 with a MOVN instruction.  Choose the sequence that yields the fewest
 number of instructions, preferring MOVZ instructions when they are both
 the same.  */
  if (ncount < zcount)
{
  emit_move_insn (gen_rtx_REG (Pmode, regnum),
  GEN_INT ((~val) & 0x));
  tval = 0x;
}
  else
{
  emit_move_insn (gen_rtx_REG (Pmode, regnum),
  GEN_INT (val & 0x));
  tval = 0;
}

The GEN_INT in the first if branch is incorrect as it truncates the immediate
at 16-bits, and so we will never generate the "MOVN" form.  What it should be
instead is: GEN_INT (~((~val) & 0x)) or equivalent.


[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

2013-05-28 Thread mgretton at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980

mgretton at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mgretton at gcc dot gnu.org

--- Comment #7 from mgretton at gcc dot gnu.org ---
Testing the testcase in #4 with a recent trunk (gcc version 4.9.0 20130528
(experimental) (GCC)) gives the following results:

arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=softfp -O2 -mthumb:
sqrlen4D_16u8:
vmovd18, r0, r1  @ v16qi
vmovd19, r2, r3
vld1.64 {d16-d17}, [sp:64]
vabd.u8 q8, q9, q8
vmull.u8q9, d16, d16
vmull.u8q8, d17, d17
vuzp.32 q9, q8
vpaddl.u16  q9, q9
vmovq10, q9  @ v4si
vpadal.u16  q10, q8
vmovr0, r1, d20  @ v4si
vmovr2, r3, d21
bx  lr


arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -O2 -mthumb:
sqrlen4D_16u8:
vabd.u8 q1, q0, q1
vmull.u8q0, d2, d2
vmull.u8q8, d3, d3
vuzp.32 q0, q8
vpaddl.u16  q0, q0
vpadal.u16  q0, q8
bx  lr

So code generation seems to be OK for hard-float ABI but the soft-float version
has some issues with an extra vmov between the vpaddl and vpadal.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-04-16 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979



--- Comment #1 from mgretton at gcc dot gnu.org 2013-04-16 12:45:38 UTC ---

Command line can be further reduced to



$ arm-none-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon

reduced-testcase.c


[Bug target/56979] New: ICE in output_operand: invalid operand for code 'P'

2013-04-16 Thread mgretton at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

 Bug #: 56979
   Summary: ICE in output_operand: invalid operand for code 'P'
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@gcc.gnu.org


Created attachment 29882
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29882
Reduced testcase

The attached testcase causes the following ICE when compiled as shown:

$ arm-none-linux-gnueabi-g++ -fsigned-char -march=armv7-a -mfloat-abi=hard
-mfpu=neon -ftree-vectorize -fPIC besttry.c
besttry.c: In function ‘float2 operator-(float, float2)’:
besttry.c:7:1: internal compiler error: output_operand: invalid operand for
code 'P'
 }
 ^
0x86acde output_operand_lossage(char const*, ...)
/work/sources/gcc-fsf/master/gcc/final.c:3303
0xcdf7ba arm_print_operand
/work/sources/gcc-fsf/master/gcc/config/arm/arm.c:18336
0x86ad2e output_operand(rtx_def*, int)
/work/sources/gcc-fsf/master/gcc/final.c:3725
0x86b70b output_asm_insn
/work/sources/gcc-fsf/master/gcc/final.c:3604
0x86b70b output_asm_insn(char const*, rtx_def**)
/work/sources/gcc-fsf/master/gcc/final.c:3493
0xcd6864 output_move_vfp(rtx_def**)
/work/sources/gcc-fsf/master/gcc/config/arm/arm.c:15383
0x86c6e8 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/work/sources/gcc-fsf/master/gcc/final.c:2853
0x86da15 final(rtx_def*, _IO_FILE*, int)
/work/sources/gcc-fsf/master/gcc/final.c:1957
0x86de29 rest_of_handle_final
/work/sources/gcc-fsf/master/gcc/final.c:4332

Issue also seen on 4.7, and 4.8.

arm-none-linux-g++ -v: 
Using built-in specs.
COLLECT_GCC=/work/builds/gcc-fsf-master/tools/bin/arm-none-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/work/builds/gcc-fsf-master/tools/libexec/gcc/arm-none-linux-gnueabi/4.9.0/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /work/sources/gcc-fsf/master/configure
--target=arm-none-linux-gnueabi --prefix=/work/builds/gcc-fsf-master/tools
--with-sysroot=/work/builds/gcc-fsf-master/sysroot-arm-none-linux-gnueabi
--disable-libssp --disable-libgomp --disable-libmudflap
--enable-languages=c,c++ --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=softfp --with-thumb : (reconfigured)
/work/sources/gcc-fsf/master/configure --target=arm-none-linux-gnueabi
--prefix=/work/builds/gcc-fsf-master/tools
--with-sysroot=/work/builds/gcc-fsf-master/sysroot-arm-none-linux-gnueabi
--disable-libssp --disable-libgomp --disable-libmudflap --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=softfp --with-thumb
target_alias=arm-none-linux-gnueabi CC=gcc --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
gcc version 4.9.0 20130416 (experimental) (GCC)

[Bug target/56484] ICE in assign_by_spills, at lra-assigns.c:1268

2013-02-28 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484



mgretton at gcc dot gnu.org changed:



   What|Removed |Added



 Target||x86_64-none-linux-gnu

   Host||x86_64-none-linux-gnu



--- Comment #2 from mgretton at gcc dot gnu.org 2013-02-28 16:18:30 UTC ---

Forgot to add gcc -v output:

Using built-in specs.

COLLECT_GCC=/work/builds/gcc-fsf-master/tools/bin/x86_64-unknown-linux-gnu-gcc

COLLECT_LTO_WRAPPER=/work/builds/gcc-fsf-master/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /work/sources/gcc-fsf/master/configure

--target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu

--build=x86_64-unknown-linux-gnu --prefix=/work/builds/gcc-fsf-master/tools

--enable-languages=c,c++,fortran

--with-ppl-include=/usr/include/x86_64-linux-gnu

Thread model: posix

gcc version 4.8.0 20130228 (experimental) (GCC)


[Bug target/56484] New: ICE in assign_by_spills, at lra-assigns.c:1268

2013-02-28 Thread mgretton at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484

 Bug #: 56484
   Summary: ICE in assign_by_spills, at lra-assigns.c:1268
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@gcc.gnu.org


Created attachment 29552
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29552
Test case

The attached test case ICEs on trunk (svn revision: 196329) as follows:

$ x86_64-unknown-linux-gnu-gcc -O2 besttry.c
besttry.c: In function ‘output_spdif’:
besttry.c:26:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1268
 }
 ^
0x7f1cf8 assign_by_spills
/work/sources/gcc-fsf/master/gcc/lra-assigns.c:1268
0x7f29b3 lra_assign()
/work/sources/gcc-fsf/master/gcc/lra-assigns.c:1425
0x7eebe1 lra(_IO_FILE*)
/work/sources/gcc-fsf/master/gcc/lra.c:2307
0x7b6e18 do_reload
/work/sources/gcc-fsf/master/gcc/ira.c:4619
0x7b6e18 rest_of_handle_reload
/work/sources/gcc-fsf/master/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Believe this is a target issue as the original test case does not trigger the
failure for arm-none-linux-gnueabihf


[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2

2013-02-05 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184



--- Comment #3 from mgretton at gcc dot gnu.org 2013-02-05 13:12:18 UTC ---

Created attachment 29358

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29358

RTL dump from reload phase


[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2

2013-02-05 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184



--- Comment #2 from mgretton at gcc dot gnu.org 2013-02-05 13:11:33 UTC ---

Created attachment 29357

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29357

RTL dump from IRA phase


[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2

2013-02-05 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184



mgretton at gcc dot gnu.org changed:



   What|Removed |Added



 CC||mgretton at gcc dot gnu.org



--- Comment #1 from mgretton at gcc dot gnu.org 2013-02-05 13:08:48 UTC ---

I can reproduce this is in a compiler targeted for arm-none-eabi (and without

needing libraries built) as follows:



Compiler configured with: /work/sources/gcc-fsf/master/configure

--target=arm-none-eabi --prefix=/work/builds/gcc-fsf-master/tools

--without-headers --with-newlib --disable-shared --disable-threads

--disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic

--without-libquadmath --disable-libquadmath --enable-languages=c,c++





./cc1plus -fpreprocessed test.ii -mthumb -march=armv7-a -mfpu=neon

-mfloat-abi=softfp -mtune=cortex-a9 -O2 -o /tmp/tmp.s



RTL dumps of 208r.ira and 208r.reload are attached from running the above

command.



The assert producing the ICE is:



  int regno = REGNO (out);

  gcc_assert (regno < FIRST_PSEUDO_REGISTER

  || reg_renumber[regno] >= 0

  || reg_equiv_constant (regno) == NULL_RTX);



out: (reg:DI 358 [315])

regno: 358

reg_renumber[regno] = -1

reg_equiv_constant (regno) = ? (Can't get GDB to print the value)


[Bug target/54974] [4.7/4.8 Regression] [ARM] [thumb] Incorrect placement of constant pools

2012-11-29 Thread mgretton at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54974



--- Comment #7 from mgretton at gcc dot gnu.org 2012-11-29 10:02:22 UTC ---

Author: mgretton

Date: Thu Nov 29 10:02:16 2012

New Revision: 193930



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193930

Log:

PR target/54974

* config/arm/arm.md (thumb2_pool_range, pool_range): Add comment on

Thumb pool ranges.

(thumb1_extendhisi2): Reduce Thumb pool range.

(arm_movdi): Likewise.

(thumb1_movdi_insn): Likewise.

(thumb1_movsi_insn): Likewise.

(pic_load_addr_unified): Likewise.

(pic_load_addr_32bit): Likewise.

(pic_load_addr_thumb1): Likewise.

(thumb1_movhf): Likewise.

(arm_movsf_soft_insn): Likewise.

(thumb1_movsf_soft_insn): Likewise.

(movdf_soft_insn): Likewise.

(thumb1_movdf_soft_insn): Likewise.

* config/arm/neon.md (*neon_mov): Likewise.

(*neon_mov): Likwise.

* config/arm/thumb2.md: (*thumb2_movsi_insn): Likewise.

(*thumb2_movhi_insn): Likewise.

(*thumb2_extendqisi_v6): Likewise.

(*thumb2_zero_extendqisi_v6): Likewise.

(*thumb2_zero_extendqisi2_v6): Likewise.

* config/arm/vfp.md: (*thumb2_movsi_vfp): Likewise.

(*movdi_vfp): Likewise.

(*movdi_vfp_cortexa8): Likewise.

(*thumb2_movsf_vfp): Likewise.

(*thumb2_movdf_vfp): Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/arm/arm.md

trunk/gcc/config/arm/neon.md

trunk/gcc/config/arm/thumb2.md

trunk/gcc/config/arm/vfp.md


[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic

2012-02-28 Thread mgretton at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534

--- Comment #4 from mgretton at gcc dot gnu.org 2012-02-28 16:17:44 UTC ---
Author: mgretton
Date: Tue Feb 28 16:17:36 2012
New Revision: 184630

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184630
Log:
PR target/51534
Add testcase forgotten in last commit, ChangeLog entry already present.


Added:
trunk/gcc/testsuite/gcc.target/arm/neon/pr51534.c


[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic

2012-02-28 Thread mgretton at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534

--- Comment #3 from mgretton at gcc dot gnu.org 2012-02-28 16:14:03 UTC ---
Author: mgretton
Date: Tue Feb 28 16:13:52 2012
New Revision: 184629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184629
Log:
PR target/51534
* gcc/config/arm/arm.c (neon_builtin_data): Add entries for vcgeu
and vcgtu.
* gcc/config/arm/arm_neon.h: Regenerate.
* gcc/config/arm/neon.md (unspec): Add UNSPEC_VCGEU, and UNSPEC_VCGTU.
(neon_vcgeu): New insn.
(neon_vcgtu): Likewise.
* gcc/config/arm/neon.ml (s_8_32, u_8_32): New lists.
(ops): Unsigned comparison intrinsics call a different
builtin.
* gcc/testsuite/gcc.target/arm/neon/pr51534.c: New testcase.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h
trunk/gcc/config/arm/neon.md
trunk/gcc/config/arm/neon.ml
trunk/gcc/testsuite/ChangeLog