The following reduced testcase shows an ICE that occurs when building 483.xalancbmk from cpu2006. class A { public: static unsigned short fgXMLString[]; }; class B { bool hasFeature() const; }; class XMLString { public: static int compareIString(const unsigned short *); static bool equals(const unsigned short *, const unsigned short *); }; const short chDigit_1 = 1; const unsigned short g1_0[]{chDigit_1}; const unsigned short g2_0[]{2}; const unsigned short g3_0[]{3, 4}; const unsigned short gRange[]{}; unsigned short *hasFeature_version; inline bool XMLString::equals(const unsigned short *p1, const unsigned short *p2) { if (p1 == 0) return false; while (*p1 == *p2) { if (!*p1) return true; p1++; p2++; } return false; } bool B::hasFeature() const { bool anyVersion = hasFeature_version == 0 || !*hasFeature_version, version1_0 = XMLString::equals(hasFeature_version, g1_0); bool version2_0 = XMLString::equals(hasFeature_version, g2_0); bool version3_0 = XMLString::equals(hasFeature_version, g3_0); if (XMLString::compareIString(A::fgXMLString) && version2_0) return true; if (anyVersion || version1_0 || version2_0 || version3_0) return true; XMLString::compareIString(gRange); } $ /home/pthaugen/install/gcc/trunk/bin/g++ -s -m64 -O2 -mcpu=power6 DOMImplementationImpl.ii DOMImplementationImpl.ii: In member function ‘bool B::hasFeature() const’: DOMImplementationImpl.ii:41:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2285 } ^ 0x10665753 maybe_record_trace_start /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2285 0x10665c27 create_trace_edges /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2379 0x10665e07 scan_trace /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2593 0x10666aa3 create_cfi_notes /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2619 0x10666aa3 execute_dwarf2_frame /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:2977 0x10666aa3 execute /home/pthaugen/src/gcc/trunk/gcc/gcc/dwarf2cfi.c:3457 Please submit a full bug report, with preprocessed source if appropriate.
Mine. Something with shrink-wrap-separate.
I'm also encountering this ICE while implementing the separate shrink-wrapping hooks on aarch64. Of course this might be a bug in my implementation of the hooks (with emission of CFA notes) but still interesting. My ICEs go away if I don't mark the saves/restores from TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS and TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS as RTX_FRAME_RELATED_P
Kyrill: Anything inconsistent in the CFI will trigger the assert there, it is most probably not the same bug.
Created attachment 39887 [details] testcase
Created attachment 39888 [details] split4 dump (right before sched2)
Created attachment 39889 [details] pro_and_epilogue dump
I get the ICE while building a libgcc variant: /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/ -B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem /opt/rtems-4.12/powerpc-rtems4.12/include -isystem /opt/rtems-4.12/powerpc-rtems4.12/sys-include -g -O2 -mcpu=8540 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _addsub_df.o -MT _addsub_df.o -MD -MP -MF _addsub_df.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_df -c /home/EB/sebastian_h/archive/gcc-git/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS
Author: segher Date: Fri Oct 28 14:39:28 2016 New Revision: 241650 URL: https://gcc.gnu.org/viewcvs?rev=241650&root=gcc&view=rev Log: sched: Do not mix prologue and epilogue insns This patch makes scheduling not reorder prologue insns relative to epilogue insns and vice versa. This fixes PR78029. The problem in that PR: We have two insns, in this order: (insn/f 300 299 267 8 (set (reg:DI 65 lr) (reg:DI 0 0)) 579 {*movdi_internal64} (expr_list:REG_DEAD (reg:DI 0 0) (expr_list:REG_CFA_RESTORE (reg:DI 65 lr) (nil)))) ... (insn/f 310 268 134 8 (set (mem/c:DI (plus:DI (reg/f:DI 1 1) (const_int 144 [0x90])) [6 S8 A8]) (reg:DI 0 0)) 579 {*movdi_internal64} (expr_list:REG_DEAD (reg:DI 0 0) (expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 1 1) (const_int 144 [0x90])) [6 S8 A8]) (reg:DI 65 lr)) (nil)))) and sched swaps them (when compiling for power6, it tries to put memory stores together, so insn 310 is moved up past 300 to go together with some other store). But the REG_CFA_RESTORE and REG_CFA_OFFSET cannot be swapped (they both say where the orig value of LR now lives). PR rtl-optimization/78029 * function.c (prologue_contains, epilogue_contains): New functions. (record_prologue_seq, record_epilogue_seq): New functions. * function.h (prologue_contains, epilogue_contains, record_prologue_seq, record_epilogue_seq): New declarations. * sched-deps.c (sched_analyze_insn): Make dependencies to prevent mixing prologue and epilogue insns. (init_deps): Initialize the new fields in struct deps_desc. * sched-int.h (struct deps_desc): New fields last_prologue, last_epilogue, and last_logue_was_epilogue. * shrink-wrap.c (emit_common_heads_for_components): Record all emitted prologue and epilogue insns. (emit_common_tails_for_components): Ditto. (insert_prologue_epilogue_for_components): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/sched-deps.c trunk/gcc/sched-int.h trunk/gcc/shrink-wrap.c
Closing as fixed. Sebastian, if you still see the problem, please open a new PR with enough information to reproduce the problem (preprocessed source, configure command, compile command).