http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418
Bug #: 54418
Summary: [4.8 Regression] [SH] Invalid operands for opcode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org
CC: olege...@gcc.gnu.org
Target: sh*-*-*
There are new libgomp failures with 4.8 compiler:
FAIL: libgomp.c++/loop-9.C -O0 (test for excess errors)
Excess errors:
/tmp/ccGZWxT0.s:8594: Error: invalid operands for opcode
The compiler outputs the invalid insn like "cmp/hs #0,reg".
Here is a reduced test case with -O0 -fopenmp.
typedef struct { } omp_sched_t;
extern "C" void abort ();
int arr[6 * 5];
void set (int loopidx, int idx)
{
for (idx = 0; idx < 5; idx++)
if (arr[4 * 5 + idx] != idx < 4)
abort ();
}
int test4 ()
{
int e = 0, idx;
{
unsigned long long j;
#pragma omp for schedule(static,1) nowait
for (j = 9223372036854775807LL - 20000ULL;
9223372036854775807LL + 10000ULL >= j;
j += 10000ULL)
{
}
}
for (idx = 0; idx < 5; idx++)
if (arr[5 * 5 + idx] != idx < 5)
abort ();
}
It seems that cmpgeusi_t insn_and_split doesn't do its work.
(define_insn_and_split "cmpgeusi_t"
[(set (reg:SI T_REG)
(geu:SI (match_operand:SI 0 "arith_reg_operand" "r")
(match_operand:SI 1 "arith_reg_or_0_operand" "rN")))]
"TARGET_SH1"
"cmp/hs %1,%0"
"&& satisfies_constraint_Z (operands[0])"
[(set (reg:SI T_REG) (const_int 1))]
Oleg, operands[0] in the splitter condition is a typo of
operands[1], doesn't it?
