[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
Renlin Li changed:
What|Removed |Added
CC||renlin.li at arm dot com,
||yufeng at gcc dot gnu.org
--- Comment #1 from Renlin Li ---
Confirm that, gcc.target/arm/mmx-2.c cause an ICE with the following
configuration.
--target=arm-none-linux-gnueabihf
--with-arch=armv7-a
--with-fpu=vfpv3-d16
--with-float=softfp
(insn 51 50 52 2 (set (reg:DI 534 [orig:139 D.4720 ] [139])
(mem/v/c:DI (plus:SI (reg/f:SI 102 sfp)
(const_int -20 [0xffec])) [0 llsink+0 S8 A64]))
mmx-2.c:4
2 447 {*iwmmxt_arm_movdi}
(nil))
(insn 573 0 0 (set (reg:DI 139 [ D.4720 ])
(reg:DI 534 [orig:139 D.4720 ] [139])) -1
(nil))
lra_constraints() keeps reloading until Max. number of reload insns
is reached.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 --- Comment #5 from Renlin Li --- (In reply to Richard Earnshaw from comment #4) > Is this fixed now? Yes, and the patch has already been committed
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 Renlin Li changed: What|Removed |Added CC||renlin.li at arm dot com --- Comment #5 from Renlin Li --- Confirm same problem while compiling glibc using arm toolchain with -march=armv7-a -O2 configuration. (In reply to David Binderman from comment #4) > (In reply to Jakub Jelinek from comment #3) > > Started with r210538. > > I am seeing something similar when compiling glibc > with trunk 20141001 with only -O2. > > ../iconv/skeleton.c: In function ‘gconv’: > ../iconv/skeleton.c:792:1: internal compiler error: in check_probability, at > basic-block.h:959 > } > ^ > 0x10685aa check_probability > ../../src/trunk/gcc/basic-block.h:959 > 0x10685aa apply_probability > ../../src/trunk/gcc/basic-block.h:988 > 0x10685aa compute_outgoing_frequencies > ../../src/trunk/gcc/cfgbuild.c:545 > 0x10685aa find_many_sub_basic_blocks(simple_bitmap_def*) > ../../src/trunk/gcc/cfgbuild.c:636 > > Code ok with 20140927.
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 --- Comment #6 from Renlin Li --- emit_case_nodes calls conditional_probability with a very large first argument. After GCOV_COMPUTE_SCALE calculation, the result overflows into a negative number. It's recorded into the cmp_and_jump rtx as a note which is later read and trigger the assertion.
[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 Renlin Li changed: What|Removed |Added CC||renlin.li at arm dot com --- Comment #1 from Renlin Li --- uminv2di is missing in this specific case.
[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 --- Comment #2 from Renlin Li --- VEC_COND_EXPR with V2DI mode is generated as aarch64 target supports it (vcond). The VEC_COND_EXPR expression will further folded into MIN_EXPR/MAX_EXPR expression in the dom pass. However, aarch64 min/max expanders don't support V2DI mode. The compiler tries to generate compare and jump sequence for this, and no vector compare can be found(aarch64 dose have one, however, the compiler uses cbranch as a key to search for a compare insn). And no library function is provided, it asserts.
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 --- Comment #8 from Renlin Li --- I believe we observed the same behavior, and the first commit to cause the ICE is r215739. The newly introduced recompute_probabilities will set the probability back to REG_BR_PROB_BASE. I will further dig into it.
[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 --- Comment #3 from Renlin Li --- I am working on this issue, and a patch is more or less done for it.
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 --- Comment #9 from Renlin Li --- r215830 fixes this ICE
[Bug target/63762] New: [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
Bug ID: 63762
Summary: [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when
hard-float abi is used
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: renlin.li at arm dot com
CC: marcus.shawcroft at arm dot com, ramana.radhakrishnan at
arm dot com
Target: arm*
Created attachment 33910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33910&action=edit
test case
This was reported on a public mailing list on 2014-10-25:
http://lists.debian.org/debian-arm/2014/10/msg00057.html
The problem is reproducible with a recent FSF compiler:
$arm-none-eabi-gcc -mfloat-abi=hard -O2 -c unpreditable-str.c
or
$arm-none-linux-gnueabihf-gcc -O2 -c unpreditable-str.c
/tmp/ccWQsFwY.s: Assembler messages:
/tmp/ccWQsFwY.s:176: Warning: source register same as write-back base
In this case the assembler is giving a warning rather than an error but the
instruction ("str r2, [r2], #4" in this case) is UNPREDICTABLE.
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #1 from Renlin Li --- I am starting to work on this issue.
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #2 from Renlin Li --- r278 is derived from r224 which is a VFP_LO_REGS. find_cost_and_classes assigns r278's class as GENERAL_REGS, and assign it hard_reg 2. Another new pseudo register r290 is created from r278, and assigned to the same hard_register and register class (GENERAL_REGS). The pref_class of r290 is derived from its original reg (r224), which is VFP_LO_REGS In lra during the hard register assignment process, conflict is checked for r302 which is a GENERAL_REGS. r290 is not considered, because of different register classes(reg_pref[290].pref_class == VFP_LO_REGS ). Hard register number 2 is chosen in this case.
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #3 from Renlin Li --- Created attachment 33957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33957&action=edit ira dump
[Bug middle-end/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 Renlin Li changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Renlin Li --- fix r217783
[Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 --- Comment #23 from Renlin Li --- I am using x86_64-unknown-linux-gnu-gcc toolchain. Reproduce the issue in 4.9 branch with "-O2 -fPIC -mtune=native" options. With 4.9.2 release, I reproduced the problem with "-O2 -fPIC -mtune=nehalem" options. I have verified that, after my patch(r217783), both cases are fixed. Issue is not there anymore in the latest trunk, it is presumably fixed by my patch already.
[Bug target/63661] [4.9 Regression] -O2 miscompiles with -mtune=nehalem or corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 Renlin Li changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Renlin Li --- 4.9 branch is fixed by r218306 trunk is fixed by r217783
