[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?
