On Mon, 12 May 2014, Hans-Peter Nilsson wrote:
On Thu, 24 Apr 2014, Jeff Law wrote:
On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
PR target/60822
2014-04-16 Segher Boessenkool seg...@kernel.crashing.org
* config/m68k/m68k.md (extendplussidi): Don't allow memory for
On Tue, 13 May 2014, Joseph S. Myers wrote:
On Mon, 12 May 2014, Hans-Peter Nilsson wrote:
On Thu, 24 Apr 2014, Jeff Law wrote:
On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
PR target/60822
2014-04-16 Segher Boessenkool seg...@kernel.crashing.org
*
On Thu, 24 Apr 2014, Jeff Law wrote:
On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
PR target/60822
2014-04-16 Segher Boessenkool seg...@kernel.crashing.org
* config/m68k/m68k.md (extendplussidi): Don't allow memory for
operand 1.
Thanks. I tweaked the comment and
On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
On Wed, Apr 16, 2014 at 02:45:28PM -0600, Jeff Law wrote:
Isn't the problem that operands 1 is a MEM which use the same register
as operands 3 in the memory address?
Yes, exactly.
ISTM either removing the memory constraint entirely, or
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
*
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
On Wed, Apr 16, 2014 at 02:45:28PM -0600, Jeff Law wrote:
Isn't the problem that operands 1 is a MEM which use the same register
as operands 3 in the memory address?
Yes, exactly.
ISTM either removing the memory constraint entirely, or splitting it off
into a separate alternative and only
