Patch to to fix bad insn generation

Jeffrey A Law
Tue Nov 30 23:59:00 GMT 1999

  In message < >you write:
  > Hi Jeff,
  >   A customer has discovered a problem with the mn10200 toolchain.
  >   (This is case 102639 in case you are interested).  The following
  >   sample code:
  >     unsigned long a = 0;
  >     unsigned long * b;
  >     unsigned long c;
  >     void
  >     func (void)
  >     {
  > 	c = b[a];
  >     }
  >   will trigger an error message from the assembler:
  >      Assembler messages:
  >     16: Error: (null)
  >     17: Error: Unrecognized opcode: `a),d0'
  >   The patch below will fix this problem.  I am not sure it is the best
  >   way to solve the problem.  Perhaps the pattern concerened ought to
  >   have constraints to distinguish between reg based and symbol based
  >   MEMs ?
  >   Is it OK to commit the patch ?
  > Cheers
  > 	Nick
  > Mon Nov 22 17:27:57 1999  Nick Clifton  <>
  > 	* config/mn10200/ Do not generate a movx
  > 	instruction if the MEM is a symbolic reference.
This seems wrong.  You're just papering over the problem.

When loading from memory:

	mov addr,dreg  performs a 16 bit load
	mov addr,areg  performs a 24 bit load
        movx addr,dreg performs a 24 bit load

Your change will turn what should be a 24bit load into a 16 bit load, that's
certainly not was intended.

The easiest way I can see to fix this is to verify that the memory address
used in operand 1 (when operand 1 is a MEM) is a valid PSImode address.

Note that truncsipsi2 has the same problem and would presumably need the
same fix.

Another alternative would be to tweak GO_IF_LEGITIMATE_ADDRESS to disallow
constant addresses SImode, but that's major overkill since the only time they
cause us problems is when we're using special memory loads to truncate an
SImode value in memory to PSImode when we want to load it into a reg.


More information about the Gcc-patches mailing list