https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800
Bug ID: 109800
Summary: [11/12/13/14 Regression] arm: ICE (segfault) loading
double with -mpure-code -mbig-endian
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.c
double f() { return 5.0; }
$ gcc/xgcc -B gcc -c -S -o /dev/null -O2 -march=armv7-m -mfloat-abi=hard
-mfpu=fpv4-sp-d16 -mbig-endian -mpure-code t.c
xgcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
It started with r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 .
Looking at the dumpfile 291r.split1, it looks like we end up splitting
indefinitely:
;; Function f (f, funcdef_no=0, decl_uid=5948, cgraph_uid=1, symbol_order=0)
Splitting with gen_split_111 (vfp.md:2138)
scanning new insn with uid = 12.
scanning new insn with uid = 13.
deleting insn with uid = 9.
Splitting with gen_split_111 (vfp.md:2138)
scanning new insn with uid = 14.
scanning new insn with uid = 15.
deleting insn with uid = 12.
Splitting with gen_split_111 (vfp.md:2138)
scanning new insn with uid = 16.
scanning new insn with uid = 17.
deleting insn with uid = 14.
I think we can adjust the splitter to avoid the new simplification introduced
above from undoing our subreg punning.
