On 04/16/14 13:18, Segher Boessenkool wrote:
operand[0] has a subreg taken (as operand[3]), which is modified
before operand[1] is used.
Built succesfully but I'm not set up to run the testsuite, sorry.
It fixes the testcase of course.
gcc/ChangeLog:
2014-04-16 Segher Boessenkool <seg...@kernel.crashing.org>
* config/m68k/m68k.md (extendplussidi): Add earlyclobber.
But in the case where writing operand3 would overwrite operand1,
shouldn't we have have used the true arm of this statement:
if (GET_CODE (operands[1]) == REG
&& REGNO (operands[1]) == REGNO (operands[3]))
output_asm_insn ("add%.l %2,%3", operands);
else
output_asm_insn ("move%.l %2,%3\;add%.l %1,%3", operands);
Looking at the .reload dump I see:
(insn 11 33 14 2 (set (reg:DI 0 %d0 [orig:47 D.1394 ] [47])
(sign_extend:DI (plus:SI (mem:SI (plus:SI (reg/v/f:SI 8 %a0
[orig:40 p ] [40])
(reg:SI 1 %d1 [44])) [3 p_4(D)->a+0 S4 A16])
(mem:SI (plus:SI (reg/v/f:SI 8 %a0 [orig:40 p ] [40])
(reg:SI 0 %d0 [45])) [3 p_4(D)->b+0 S4 A16]))))
j.c:12 78 {extendplussidi}
Isn't the problem that operands 1 is a MEM which use the same register
as operands 3 in the memory address?
ISTM either removing the memory constraint entirely, or splitting it off
into a separate alternative and only earlyclobbering that alternative
would be better.
Or am I missing something?
jeff