Created attachment 26085 [details] Preprocessed test case xgcc (GCC) 4.7.0 20111214 (experimental) [trunk revision 182330] Target: bfin-rtems4.11 compiling newlib /home2/joel/build/b-bfin-gcc/./gcc/xgcc -B/home2/joel/build/b-bfin-gcc/./gcc/ -nostdinc -B/home2/joel/build/b-bfin-gcc/bfin-rtems4.11/newlib/ -isystem /home2/joel/build/b-bfin-gcc/bfin-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/bfin-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/bfin-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/bfin-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/bfin-rtems4.11/sys-include -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I/users/joel/test-gcc/gcc-svn/newlib/libc/string -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin -g -O2 -c -o lib_a-strsignal.o `test -f 'strsignal.c' || echo '/users/joel/test-gcc/gcc-svn/newlib/libc/string/'`strsignal.c /tmp/cctEZ5VY.s: Assembler messages: /tmp/cctEZ5VY.s:24: Error: syntax error. Input text was .LCFI1. /tmp/cctEZ5VY.s:24: Error: Cutting this down, it appears to be the -g flag: [joel@rtbf64a string]$ /home2/joel/build/b-bfin-gcc/./gcc/xgcc -B/home2/joel/build/b-bfin-gcc/./gcc/ -O2 -c -fno-builtin j.c [joel@rtbf64a string]$ /home2/joel/build/b-bfin-gcc/./gcc/xgcc -B/home2/joel/build/b-bfin-gcc/./gcc/ -O2 -c -g -fno-builtin j.c /tmp/ccwaXpNe.s: Assembler messages: /tmp/ccwaXpNe.s:24: Error: syntax error. Input text was .LCFI1. /tmp/ccwaXpNe.s:24: Error: The bad asm generated is here: .LCFI0: R2 = ROT R0 BY 0 || .LCFI1: R7 = [P2] || nop; I am guessing there should have been a semi-colon and maybe a nop before .LCFI1.
This was caused by r177218 for PR target/49864.
(gdb) p insn $23 = (rtx) 0x7ffff701b180 (gdb) pr (parallel [ (unspec [ (const_int -4 [0xfffffffffffffffc]) ] 5) (set/f (mem:SI (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffffffffffffffc])) [0 S4 A32]) (reg:SI 7 R7)) (set/f (reg/f:SI 14 SP) (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffffffffffffffc]))) Before that commit, dwarf2out_frame_debug_expr (insn) will set any_cfis_emitted in dwarf2out_frame_debug, which will cause dwarf2out_flush_queued_reg_saves to emit the CFI. But after that commit, dwarf2out_frame_debug_expr (insn) will not set any_cfis_emitted.
Well, honestly the largest problem is that the bfin backend is emitting bundles in a way that can't be split, but in separate insns. The ia64 backend handles this case by supporting "debug labels" in the assembler, which are understood not to break the bundle. As far as the middle-end is concerned, it's doing absolutely nothing wrong. I'll see what I can do to restore the kinda-sorta working state that we had before, but you really ought to fix the backend to not lie to the middle-end. Consider implementing debug labels in the assembler. Or failing that, pack your insn bundles into sequences, or something.
Mine. The only thing I'll concede is that this is a debug size regression from 4.6, as there's an unnecessary advance between the two cfi opcodes.
Author: rth Date: Wed Dec 21 20:21:00 2011 New Revision: 182604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182604 Log: PR target/51552 * dwarf2cfi.c (dwarf2out_frame_debug): Move any_cfis_emitted code... (scan_trace): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2cfi.c
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01577.html