[Bug rtl-optimization/71878] ICE in cselib_record_set
thopre01 at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Jul 14 12:20:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878
Thomas Preud'homme <thopre01 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |arm-none-eabi
Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org
Target Milestone|--- |5.5
Summary|ICE in |ICE in cselib_record_set
Known to fail| |5.4.1
--- Comment #2 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
Hi,
The attached testcase (extracted from gcc.dg/vect/slp-perm-5) ICEs on GCC 5 +
backport of r227382 on arm-none-eabi when compiled with -mcpu=cortex-a8 -marm
-mfpu=neon -mfloat-abi=softfp -ftree-vectorize -O2 and gives the following
stacktrace:
/home/thopre01/issues/sjp/slp-perm-5.c: In function ‘foo’:
/home/thopre01/issues/sjp/slp-perm-5.c:44:1: internal compiler error: in
cselib_record_set, at cselib.c:2396
}
^
0x653c37 cselib_record_set
/data/dev/repos/internal/gcc/gcc/cselib.c:2396
0x653c37 cselib_record_sets
/data/dev/repos/internal/gcc/gcc/cselib.c:2613
0x654237 cselib_process_insn(rtx_insn*)
/data/dev/repos/internal/gcc/gcc/cselib.c:2686
0x89e547 reload_cse_regs_1
/data/dev/repos/internal/gcc/gcc/postreload.c:248
0x89fcab reload_cse_regs
/data/dev/repos/internal/gcc/gcc/postreload.c:94
0x89fcab execute
/data/dev/repos/internal/gcc/gcc/postreload.c:2387
This is due to LRA allocating the same hard register to the two destinations
registers of neon_vtrn<mode>_insn pattern (in config/arm/neon.md).
GCC was configured with --target=arm-none-eabi only.
LRA produces the following insn:
(insn 77 61 154 2 (parallel [
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN1))
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN2))
]) pr71878.c:41 1940 {*neon_vtrnv4si_insn}
(nil))
This causes cselib to fail when processing the second SET of that parallel in
cselib_record_set () because of the assert gcc_assert (REG_VALUES (dreg)->elt
== 0) since the field was already set when processing the first SET.
More information about the Gcc-bugs
mailing list