The following testcase:
---------------------------------------------------------------------------
volatile int g[32];
long long gll;
double gd;
#define MULTI(X) \
X( 1), X( 2), X( 3), X( 4), X( 5), X( 6), X( 7), X( 8), X( 9), X(10), \
X(11), X(12), X(13), X(14), X(15), X(16), X(17), X(18), X(19), X(20), \
X(21), X(22), X(23), X(24), X(25), X(26), X(27), X(28), X(29), X(30)
#define DECLARE(INDEX) x##INDEX
#define COPY_IN(INDEX) x##INDEX = g[INDEX]
#define COPY_OUT(INDEX) g[INDEX] = x##INDEX
void
test (int n)
{
union { long long l; double d; } u = { 0x12345678 };
gll = u.l;
int MULTI (DECLARE);
MULTI (COPY_IN);
MULTI (COPY_OUT);
MULTI (COPY_OUT);
MULTI (COPY_OUT);
gd = u.d;
}
---------------------------------------------------------------------------
fails for mips*-elf targets when compiled with -G0 and with
optimisation enabled:
internal compiler error: in emit_move_insn, at expr.c:3317
The pseudo register that holds "u" is not allocated a hard
register, so we rematerialise the constant 0x1234567 on demand.
However, find_reloads_toplev assumes that simplified subregs of
such constants also satisfy LEGITIMATE_CONSTANT_P. This isn't
true here: the original 0x1234567 CONST_INT is legitimate,
but the equivalent DFmode CONST_DOUBLE is not.
I think the fix is to force the subregged constant into the
constant pool if it isn't itself legitimate. I'm testing a fix.
(I came across this while working on another patch. The original
test was more natural; the one above was just reverse-engineered
after the fact.)
--
Summary: Invalid rematerialisation of subregs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: mipsisa64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32897
