[ forwarded from http://bugs.debian.org/421799 ] seen with 20070426 CVS The opcode check for the lswi instruction is overstrict: | $ cat test.S | lswi 5,24,0 | $ as test.S | test.S: Assembler messages: | test.S:1: Error: operand out of range (0 is not between 1 and 32) The IBM reference say: | lswi RT, RA, NB | NB is the byte count. | N is NB, which is the number of bytes to load. If NB is 0, then N is 32.
Did someone hit this in real code? I've always taken the description in the reference manual to mean the field rather than what is specified on the assembly line. Quite obviously, a value of 0 in the 5-bit field means transfer 32 bytes, but it seems reasonable to me that a 0 as the third arg for lswi in assembler be rejected. You can't transfer zero bytes using lswi.
Hmm, I guess there isn't any harm in allowing a zero in the third arg to mean 32.
seen in linux-2.6.21 build by a Debian maintainer: CC arch/powerpc/kernel/binfmt_elf32.o {standard input}: Assembler messages: {standard input}:988: Error: operand out of range (0 is not between 1 and 32) {standard input}:989: Error: operand out of range (0 is not between 1 and 32)
Eep, I see. gcc/config/rs6000.c:expand_block_move masks the byte count to 5 bits.
http://sourceware.org/ml/binutils-cvs/2007-04/msg00194.html