[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Ryan Mansfield from comment #12)
> /home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/xgcc
> -B/home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/
> -B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/bin/
> -B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/lib/
> -isystem
> /home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/
> include -isystem
> /home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-
> include    -g -Os -O2  -g -Os -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
> -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC
> -fno-inline -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/.
> -I../../../libgcc/../gcc -I../../../libgcc/../include  -DHAVE_CC_TLS  -o
> pr-support.o -MT pr-support.o -MD -MP -MF pr-support.dep -fexceptions -c
> ../../../libgcc/config/arm/pr-support.c -fvisibility=hidden -DHIDE_EXPORTS
> In file included from ./unwind.h:30:0,
>                  from ../../../libgcc/config/arm/pr-support.c:24:
> /home/ryan/gnu/gcc/trunk/arm-eabi/gcc/include/unwind-arm-common.h: In
> function '_Unwind_GetGR.constprop':
> /home/ryan/gnu/gcc/trunk/arm-eabi/gcc/include/unwind-arm-common.h:225:5:
> internal compiler error: in arm_unwind_emit_sequence, at
> config/arm/arm.c:28777
>      }
>      ^
> 0xbef8a5 arm_unwind_emit_sequence
> 	../../gcc/config/arm/arm.c:28777
> 0xbef8a5 arm_unwind_emit
> 	../../gcc/config/arm/arm.c:28999
> 0x708bde final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
> 	../../gcc/final.c:2978
> 0x709585 final(rtx_def*, _IO_FILE*, int)
> 	../../gcc/final.c:2024
> 0x7099a9 rest_of_handle_final
> 	../../gcc/final.c:4438
> 0x7099a9 execute
> 	../../gcc/final.c:4513
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> ../../../libgcc/static-object.mk:17: recipe for target 'pr-support.o' failed
> make: *** [pr-support.o] Error 1

Ah, ok, I see, arm_unwind_emit_sequence is being passed the
REG_FRAME_RELATED_EXPR sequence.  So, I guess the primary question is, do you
want to emit:
        stmfd   sp!, {r0, r1, r2, r4, r5, lr}
        .save {r0, r1, r2, r4, r5, lr}
or:
        stmfd   sp!, {r0, r1, r2, r4, r5, lr}
        .save {r4, r5, lr}
        .pad #12
when r0/r1/r2 have been added just to align the thing?
For the latter case (which I think is conceptually better, the r0/r1/r2 really
don't need to be saved) I think it would be enough just to look at the sp
offsets where each register is saved and figure out the gaps.  Before my patch
the only gap could be PC register as the topmost one.  With my patch there can
be also a gap at the very bottom.

Anyway, it would be nice to hear ARM maintainers about this.