With a cross-compiler from x86_64-pc-linux-gnu to powerpc64le-unknown-linux-gnu compiling this file with -g -O2 -fsplit-stack -fno-omit-frame-pointer crashes. void trap () { __builtin_trap (); } during RTL pass: dwarf2 /usr/local/google/home/iant/foo.c: In function 'trap': /usr/local/google/home/iant/foo.c:1:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2348 void trap () { __builtin_trap (); } ^~~~ 0x791f8d maybe_record_trace_start /tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2348 0x792524 scan_trace /tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2541 0x7934a7 create_cfi_notes /tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2689 0x7934a7 execute_dwarf2_frame /tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:3057 0x7934a7 execute /tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:3545 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://go.ext.google.com/go/> for instructions. The 312r.dwarf2 file shows: ;; Function runtime.Breakpoint (runtime.Breakpoint, funcdef_no=1318, decl_uid=22 712, cgraph_uid=829, symbol_order=13584) Creating trace 0 : start at note 1 Creating trace 1 : start at code_label 25 Creating trace 2 : start at code_label 39 Creating trace 3 : start at note 29 Processing trace 0 : start at note 1 saw edge from trace 0 to 2 (via jump_insn 18) push trace 2 to worklist saw edge from trace 0 to 1 (via fallthru 0) push trace 1 to worklist Processing trace 1 : start at code_label 25 Processing trace 2 : start at code_label 39 saw edge from trace 2 to 3 (via fallthru 0) push trace 3 to worklist Processing trace 3 : start at note 29 saw edge from trace 3 to 1 (via jump_insn 40) Inconsistent CFI state! SHOULD have: .cfi_def_cfa 1, 0 DO have: .cfi_def_cfa 1, 0 .cfi_offset 65, 16
The problem occurs in 296r.rtl_dce, where the insn restoring lr after the __morestack call is deleted. That leads to the mismatch in cfi state. Well, OK, lr can be trashed in a function that won't return so deleting the lr restore in itself isn't wrong. But if we want a consistent cfi state that can't happen without also deleting the instructions saving lr. Which won't occur due to hacks to stop regrename breaking things. I think the easiest solution is to make split_stack_return depend on lr (which of course it does!).
Testing what should be an obvious fix.
Author: amodra Date: Sat Feb 10 04:49:15 2018 New Revision: 257549 URL: https://gcc.gnu.org/viewcvs?rev=257549&root=gcc&view=rev Log: PR84300, ICE in dwarf2cfi on ppc64le with -fsplit-stack -fno-omit-frame-pointer PR target/84300 gcc/ * config/rs6000/rs6000.md (split_stack_return): Remove (use ..). Specify LR as an input. gcc/testsuite/ * gcc.dg/pr84300.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr84300.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
Fixed. Doesn't appear to affect gcc-7 or earlier.