Confirmed in lm32-rtems4.11-gcc (GCC) 4.9.2 20141028 (prerelease)

But now at:

$ ~/test-gcc/install-head/bin/lm32-rtems4.11-gcc -O2 -g -c /tmp/fastlz.c 
In file included from ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:113:0:
../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c: In function 'fastlz1_compress':
../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:418:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1675
0x52ddb0 dwarf2out_frame_debug_expr
	../../gcc/gcc/dwarf2cfi.c:1675
0x52e3ac dwarf2out_frame_debug
	../../gcc/gcc/dwarf2cfi.c:2043
0x52e3ac scan_insn_after
	../../gcc/gcc/dwarf2cfi.c:2369
0x52fc37 scan_trace
	../../gcc/gcc/dwarf2cfi.c:2526
0x530690 create_cfi_notes
	../../gcc/gcc/dwarf2cfi.c:2565
0x530690 execute_dwarf2_frame
	../../gcc/gcc/dwarf2cfi.c:2925
0x530690 execute
	../../gcc/gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.

Broken on head as well.

lm32-rtems4.11-gcc (GCC) 5.0.0 20141104 (experimental)

Added the dwarf maintainers hoping to get an answer. From an RTEMS perspective, the lm32 is not usable. Both 4.9 and the head are broken. Hoping you two have an idea. Happy to help since this is a cross target.

(In reply to Joel Sherrill from comment #3)
> Added the dwarf maintainers hoping to get an answer. From an RTEMS
> perspective, the lm32 is not usable. Both 4.9 and the head are broken.
> Hoping you two have an idea. Happy to help since this is a cross target.

This is a target problem.

Please see stack_adjust function, where emit_move_insn is used to move an immediate to r10. However, emit_move_insn with (const_int -32812) generates two insn sequence:

(insn 952 123 953 2 (set (reg:SI 10 r10)
        (const_int -65536 [0xffffffffffff0000])) ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1
     (nil))
(insn/f 953 952 954 2 (set (reg:SI 10 r10)
        (ior:SI (reg:SI 10 r10)
            (const_int 32724 [0x7fd4]))) ../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1
     (expr_list:REG_EQUAL (const_int -32812 [0xffffffffffff7fd4])
        (nil)))

However:

      /* r10 is caller saved so it can be used as a temp reg.  */
      rtx r10;
      r10 = gen_rtx_REG (word_mode, 10);
      insn = emit_move_insn (r10, GEN_INT (amount));
      if (amount < 0)
	RTX_FRAME_RELATED_P (insn) = 1;

emit_move_insn returns only the *last* insn of the sequence (insn 953 in the above dump). (insn 952) doesn't get RTX_FRAME_RELATED_P flag set - please note lack of /f modifier - and consequently dwarf2out_frame_debug_expr trips in Rule 7 due to unknown cfa_temp.reg (which would be otherwise initialized in insn 952, following Rule 6).

So, considering that emit_move_insn can generate a sequence of insns, but only the last insn is returned as a return value of a function,

      insn = emit_move_insn (r10, GEN_INT (amount));
      RTX_FRAME_RELATED_P (insn) = 1;

is not the correct way to set /f flags to all insn of the generated sequence.

(In reply to Uroš Bizjak from comment #4)
 
> is not the correct way to set /f flags to all insn of the generated sequence.

Please see how mips/mips.c annotates expanded sequences using mips_set_frame_expr, especially stack pointer adjustment description in mips.c, around line 11620.

I am not an expert on the machine descriptions or the lm32. If someone wants to propose a patch, I am happy to test it.

I added Jon Beniston who did the initial port and Sebastien Bourdeauducq who is listed as the lm32 maintainer but hasn't committed since 2011. I hope one of them can help out here.

We are using gcc 4.9.3 for RTEMS 4.11 and gcc 6.3.0 on RTEMS 4.12. This doesn't happen on either GCC. So closing.

See previous comment. Appears to be fixed.