Hi, Joseph, On Feb 9, 2018, Joseph Myers <jos...@codesourcery.com> wrote:
> sh4 is: > during RTL pass: final > In file included from strtof_l.c:45: > strtod_l.c: In function '____strtof_l_internal': > strtod_l.c:1769:1: internal compiler error: Segmentation fault > } > ^ > 0xb98e3f crash_signal > /scratch/jmyers/glibc-bot/src/gcc/gcc/toplev.c:325 > 0x856b18 maybe_output_next_view > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:1726 > 0x856b18 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2714 > 0xef36bc print_slot > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2557 > 0xef6520 output_far_jump(rtx_insn*, rtx_def*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2617 > 0x857098 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:3101 > 0x856c26 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2806 > 0x858469 final_1 > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2088 > 0x8591d8 rest_of_handle_final > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4637 > 0x8591d8 execute > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4711 > Since it's in maybe_output_next_view, I think it probably comes from these > patches. Thanks for the backtraces. The problem is that ports call final_scan_insn recursively passing NULL for seen, but now there is code that actually cares about carrying information around in it. I decided against silencing the errors by testing seen for non-NULL before dereferencing it, and instead arranging for the outermost pointer to be recovered in recursive calls. I hope this is enough to cover all the cases of final_scan_insn being called from ports. Could you possibly give it a spin, pretty please with sugar on top? ;-) Thanks a ton, (I'll provide a ChangeLog for formal review and hopefully approval once it has gone through more than my initial smoke testing on x86_64, but my own testing will take some time, and I wanted to give you something that at least stood a chance of fixing the problem before crashing in bed :-) [LVU] deal with md final_scan_insn From: Alexandre Oliva <aol...@redhat.com> Ports call final_scan_insn with seen == NULL, and then maybe_output_next_view crashes because it assumes it's non-NULL. Oops. Fixed. --- gcc/final.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/gcc/final.c b/gcc/final.c index c311c198da67..a60be5ddc31c 100644 --- a/gcc/final.c +++ b/gcc/final.c @@ -2236,9 +2236,9 @@ asm_show_source (const char *filename, int linenum) debug information. We force the emission of a line note after both NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG. */ -rtx_insn * -final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED, - int nopeepholes ATTRIBUTE_UNUSED, int *seen) +static rtx_insn * +final_scan_insn_1 (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED, + int nopeepholes ATTRIBUTE_UNUSED, int *seen) { #if HAVE_cc0 rtx set; @@ -3204,6 +3204,34 @@ final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED, } return NEXT_INSN (insn); } + +/* This is a wrapper around final_scan_insn_1 that allows ports to + call it recursively without a known value for SEEN. The value is + saved at the outermost call, and recovered for recursive calls. */ + +rtx_insn * +final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p, + int nopeepholes, int *seen) +{ + static int *enclosing_seen; + static int recursion_counter; + + gcc_assert (seen || recursion_counter); + gcc_assert (!recursion_counter || !seen || seen == enclosing_seen); + + if (!recursion_counter++) + enclosing_seen = seen; + else if (!seen) + seen = enclosing_seen; + + rtx_insn *ret = final_scan_insn_1 (insn, file, optimize_p, nopeepholes, seen); + + if (!--recursion_counter) + enclosing_seen = NULL; + + return ret; +} + /* Return whether a source line note needs to be emitted before INSN. Sets IS_STMT to TRUE if the line should be marked as a possible >> (It's possible more failures might appear on other architectures once the >> bot builds the glibc testsuite, that's just failures from building GCC and >> glibc.) > hppa has a similar ICE building glibc tests, also in > maybe_output_next_view, so probably also from these patches: > during RTL pass: final > test-tgmath2.c: In function 'test_fma_3': > test-tgmath2.c:421:1: internal compiler error: Segmentation fault > } > ^ > 0xb7525f crash_signal > /scratch/jmyers/glibc-bot/src/gcc/gcc/toplev.c:325 > 0x835f14 maybe_output_next_view > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:1726 > 0x835f14 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2714 > 0xed7761 pa_output_call(rtx_insn*, rtx_def*, int) > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/pa/pa.c:8019 > 0x83642b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:3101 > 0x836026 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2806 > 0x837629 final_1 > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2088 > 0x8389d6 rest_of_handle_final > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4637 > 0x8389d6 execute > /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4711 -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer