Cross m68k assembler on powerpc-apple-darwin is not able to assemble following instruction: fmovem.l %fpcr,%d1 Terminal output: [bobik:/tmp] thurka% uname -a Darwin bobik 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu -517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc [d-eprg05-75-98:/tmp] thurka% cat bug.s fmovem.l %fpcr,%d1 [bobik:/tmp] thurka% ~/Projects/gcc_m68k/bin/m68k-bsd-elf-as -v -m68040 bug.s GNU assembler version 2.16 (m68k-bsd-elf) using BFD version 2.16 bug.s: Assembler messages: bug.s:1: Error: operands mismatch -- statement `fmovem.l %fpcr,%d1' ignored [bobik:/tmp] thurka%
Created attachment 503 [details] source file to trigger this bug
I believe that this bug is caused by two separate problems in gas/config/tc-m68k.c file. First problem is in operands matching against opcode table (function m68k_ip, big for-loop around line 1216). Information in the_ins.operands array are in some cases modified during operands matching (case 'L' and case 'l' in big switch). Subsequently such modified operand fails to match against correct opcode operands and instruction is rejected. Second problem is that function m68k_compare_opcode does not correctly compare instructions with the same name. The intension was that this function should honor order in opcode table, but if op1 and op2 has same names and op1 < op2 than m68k_compare_opcode return 0 instead of 1. Depending on implementation of qsort this may produce different results. I believe that this is reason why I cannot reproduce this bug on i386-redhat-linux, because on i386-redhat-linux the order of fmovem.l opcodes is different from powerpc-apple-darwin and does not trigger the problem with operands matching. Order of fmovem.l on powerpc: IiL8~s Iis8%s Ii*lL8 order on i386-redhat-linux: Iis8%s IiL8~s Ii*lL8 I will attach patches to fix both problems mentioned above.
Created attachment 504 [details] Proposed patch to fix problem with operand matching
Created attachment 505 [details] Proposed patch to fix problem with opcode ordering
Proposed fix also fixed the problem reported in http://lists.gnu.org/archive/html/bug-binutils/2005-06/msg00000.html
Hi Tom, Thanks for reporting this problem and submit the patches to fix it. I have checked them in, with a little tidying up of the formatting and a few comments added, and I also created this ChangeLog entry: 2005-06-08 Tomas Hurka <tom@hukatronic.cz> PR991 * config/tc-m68k.c (m68k_ip): Test for insn compatiblity using a temporary copy of the operands array so that changes can be safely backed out if the insn does not match. (m68k_compare_opcode): Shortcut the test when the parameters are the same. Return 1 if the names match but the second opcode is further on in the array than the first. Cheers Nick