[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #15 from Arseny Solokha --- *** Bug 71629 has been marked as a duplicate of this bug. ***
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Joseph S. Myers --- Fixed by the given commit.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #13 from Peter Bergner --- Author: bergner Date: Thu Nov 24 02:07:51 2016 New Revision: 242818 URL: https://gcc.gnu.org/viewcvs?rev=242818=gcc=rev Log: gcc/ PR target/78458 * config/rs6000/rs6000.h (HARD_REGNO_CALLER_SAVE_MODE): Return MODE if it is at least NREGS wide. gcc/testsuite/ PR target/78458 * gcc.target/powerpc/pr78458.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr78458.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h trunk/gcc/testsuite/ChangeLog
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #12 from joseph at codesourcery dot com --- Applying also the third patch Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 242751) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -8443,14 +8443,13 @@ rs6000_legitimate_offset_address_p (machine_mode m case TFmode: case IFmode: case KFmode: +case TDmode: +case TImode: +case PTImode: if (TARGET_E500_DOUBLE) return (SPE_CONST_OFFSET_OK (offset) && SPE_CONST_OFFSET_OK (offset + 8)); - /* fall through */ -case TDmode: -case TImode: -case PTImode: extra = 8; if (!worst_case) break; results in glibc compiling successfully and the compilation parts of the testsuite running OK; not yet done any execution testing with these patches. The bad offset came from an insn: (insn 115 1209 1210 (set (reg:DF 27 27 [orig:294 _129 ] [294]) (subreg:DF (mem/c:TI (plus:SI (reg/f:SI 1 1) (const_int 256 [0x100])) [14 %sfp+256 S16 A128]) 0)) 1909 {*frob_df_ti} (nil))
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #11 from joseph at codesourcery dot com --- For e500v2, that patch moves things from a libgcc build failure to a glibc build failure having built libgcc successfully: many files in glibc fail to build with errors of the form: ../sysdeps/ieee754/ldbl-128ibm/s_modfl.c: In function '__modfl': ../sysdeps/ieee754/ldbl-128ibm/s_modfl.c:91:1: error: unrecognizable insn: } ^ (insn 31 30 32 2 (set (reg:DF 203) (subreg:DF (reg:TI 202) 8)) "../sysdeps/ieee754/ldbl-128ibm/s_modfl.c":44 -1 (nil)) ../sysdeps/ieee754/ldbl-128ibm/s_modfl.c:91:1: internal compiler error: in extract_insn, at recog.c:2311 I think it would be reasonable for you to submit your patch for inclusion at this point, as a useful incremental improvement. The above error is fixed by a patch Index: gcc/config/rs6000/spe.md === --- gcc/config/rs6000/spe.md(revision 242699) +++ gcc/config/rs6000/spe.md(working copy) @@ -2314,6 +2314,18 @@ } }) +(define_insn "*frob__ti_8" + [(set (match_operand:SPE64 0 "nonimmediate_operand" "=r") +(subreg:SPE64 (match_operand:TI 1 "input_operand" "r") 8))] + "(TARGET_E500_DOUBLE && mode == DFmode) + || (TARGET_SPE && mode != DFmode)" +{ + if (WORDS_BIG_ENDIAN) +return "evmergelo %0,%Y1,%Z1"; + else +return "evmergelo %0,%Z1,%Y1"; +}) + (define_insn "*frob_tf_ti" [(set (match_operand:TF 0 "gpc_reg_operand" "=r") (subreg:TF (match_operand:TI 1 "gpc_reg_operand" "r") 0))] (I'm familiar with this part of spe.md). That moves the error to an assembler error from GCC generating bad offsets building s_fmal.o /tmp/ccLQIeP5.s: Assembler messages: /tmp/ccLQIeP5.s:735: Error: operand out of range (256 is not between 0 and 248) which I need to investigate further.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #10 from Peter Bergner --- (In reply to Peter Bergner from comment #9) > I'm testing the following patch (which is a little more general) on a > powerpc64le-linux bootstrap to see if this survives. Ok, this patch passed bootstrap and regtesting on powerpc64le-linux with no regressions. Joseph, can you try the patch above and see if it passes bootstrap and regresting on a powerpc-linux-gnuspe build?
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #9 from Peter Bergner --- The IFmode usage is coming from HARD_REGNO_CALLER_SAVE_MODE(8, 2, TFmode) returning IFmode, which comes from choose_hard_reg_mode (8, 2, false). As a quick hack, I modified HARD_REGNO_CALLER_SAVE_MODE() to instead return TFmode, and it didn't ICE. I'm testing the following patch (which is a little more general) on a powerpc64le-linux bootstrap to see if this survives. Index: gcc/config/rs6000/rs6000.h === --- gcc/config/rs6000/rs6000.h (revision 241976) +++ gcc/config/rs6000/rs6000.h (working copy) @@ -1279,9 +1279,11 @@ enum data_align { align_abi, align_opt, enough space to account for vectors in FP regs. However, TFmode/TDmode should not use VSX instructions to do a caller save. */ #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ - (TARGET_VSX \ - && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE)) \ - && FP_REGNO_P (REGNO) \ + (NREGS <= rs6000_hard_regno_nregs[MODE][REGNO] \ + ? MODE \ + : TARGET_VSX \ + && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE)) \ + && FP_REGNO_P (REGNO) \ ? V2DFmode \ : TARGET_E500_DOUBLE && (MODE) == SImode\ ? SImode\
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #8 from Peter Bergner --- Last one, I promise. We don't need _Complex at all: extern void bar (void); long double foo (long double p1) { bar (); asm volatile ("# clobbers" ::: "r14", "r15", "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31"); return p1; }
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #7 from Peter Bergner --- Here's a smaller test case that induces spilling which leads to our ICE: extern void bar (void); _Complex foo (long double p1) { _Complex e; bar (); asm volatile ("# clobbers" ::: "r14", "r15", "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31"); __imag__ e = p1; return e; }
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #6 from Peter Bergner --- This whole lra reload is due to us trying to split insns like the following: (insn 129 281 264 9 (set (subreg:TF (reg:TI 315 [orig:262 p1 ] [262]) 0) (reg/v:TF 173 [ p1 ])) "pr78458.i":17 1930 {*frob_ti_tf_2} (expr_list:REG_DEAD (reg/v:TF 173 [ p1 ]) (nil))) Old reload just leaves the insn alone.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #5 from Peter Bergner --- gdb show we don't like: (gdb) frame 1 #1 0x10a7d328 in lra_set_insn_recog_data (insn=0x3fffb5584340) at /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:963 963 gcc_assert (GET_CODE (PATTERN (insn)) == USE (gdb) pr insn (insn 281 280 129 9 (set (subreg:SI (reg/v:TF 173 [ p1 ]) 12) (subreg:SI (reg:IF 325) 12)) "pr78458.i":17 -1 (nil)) Looking at the -mno-lra output, it's interesting that we don't have any use of IFmode anywhere.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-22 CC||bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Peter Bergner --- Confirmed with the following creduced test case: bergner@genoa:~/gcc/BUGS/GNU_SPE$ cat pr78458.i long double a, f, g, h, i; long double b, c, d, k; _Complex foo (long double p1) { _Complex e; a = k * h; b = p1 * g; if (__builtin_expect(c, 0) && __builtin_expect(d, 0)) { long double j = __builtin_expect(k, 0); if (__builtin_expect(j, 0)) p1 = __builtin_copysignl(1, p1); a = b = b - i; if (f) d = h + p1 * g; } e = c; __imag__ e = d; return e; } bergner@genoa:~/gcc/BUGS/GNU_SPE$ /home/bergner/gcc/build/gcc-fsf-mainline-gnuspe/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-gnuspe/gcc -O2 -mcpu=8548 -S pr78458.i pr78458.i: In function ‘foo’: pr78458.i:22:1: internal compiler error: in lra_set_insn_recog_data, at lra.c:965 } ^ 0x10a7d327 lra_set_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:963 0x10a7a177 lra_get_insn_recog_data /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-int.h:487 0x10a7fc8f lra_update_insn_regno_info(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1585 0x10a806af lra_push_insn_1 /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1736 0x10a80713 lra_push_insn(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1744 0x10a80973 push_insns /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1787 0x10a80ca7 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*) /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:1835 0x10aa6f5f split_reg /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:5369 0x10aab417 inherit_in_ebb /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:6178 0x10aab8d3 lra_inheritance() /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra-constraints.c:6248 0x10a82cf3 lra(_IO_FILE*) /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/lra.c:2403 0x109fe61f do_reload /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/ira.c:5381 0x109fee53 execute /home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-base/gcc/ira.c:5565
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #3 from joseph at codesourcery dot com --- I still get the same ICE at r242683.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 --- Comment #2 from joseph at codesourcery dot com --- It was r242641.
[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #1 from Michael Meissner --- What subversion id did you build with? Was it before or after subversion id 242679 which was my last checkin to movdi in rs6000.md?