[Bug gas/25848] cmpi to local label produces wrong code on 68000
https://sourceware.org/bugzilla/show_bug.cgi?id=25848 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #5 from Thorsten Otto --- There still seems to be a problem. A cmp #8,0(pc) is now rejected for 68000, although the restriction only applies to cmpi, not cmp. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27190] New: m68k: fmovemx does not accept pc-relative addressing modes for memory-to-register transfers
https://sourceware.org/bugzilla/show_bug.cgi?id=27190 Bug ID: 27190 Summary: m68k: fmovemx does not accept pc-relative addressing modes for memory-to-register transfers Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 13121 --> https://sourceware.org/bugzilla/attachment.cgi?id=13121&action=edit Add fix for gas not allowing pc-relative addressing for fmovemx , Assembling an instruction like fmovem.x addr(%pc),%fp0-%fp1 Is rejected by gas. For memory-to-register-transfers, it should also allow pc-relative addressing modes. Attached is proposed fix (changes the "alterable-control" flag to "control" for those instructions). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27191] New: m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr
https://sourceware.org/bugzilla/show_bug.cgi?id=27191 Bug ID: 27191 Summary: m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- When using immediate data for a fmovem.l to control register, and more than one register ist specified, only a single constant is written: fmovem.l#0x,%fpsr/%fpcr nop result: 0: f23c 9800 fmoveml #0,%fpsr/%fpcr 6: 8: 4e71nop Only the low 32-bit value was written. Specifying for example fmovem.l#0x,%fpsr/%fpcr/%fpiar nop does not work at all, because the constant overflows. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27191] m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr
https://sourceware.org/bugzilla/show_bug.cgi?id=27191 --- Comment #2 from Thorsten Otto --- Are you sure about this? I can't find any indication for that in the manual. Only register-direct are flagged as being allowed only for a single register. And actually, that is instruction is emulated, and also tested, by the FPSP060 support package: https://github.com/torvalds/linux/blob/1d94330a437a573cfdf848f6743b1ed169242c8a/arch/m68k/ifpsp060/src/ftest.S#L647 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27211] New: m68k: word branches are not checked for signed overflow
https://sourceware.org/bugzilla/show_bug.cgi?id=27211 Bug ID: 27211 Summary: m68k: word branches are not checked for signed overflow Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- When the branch target is known, gas should reject values that overflow the range of a *signed* value. That is, code such as .text braw loopend .REPT 2 nop .ENDR loopend: should give an error. Instead, an (incorrect) negative value is written. Note that ld gives a warning at least, if the target is not known and defined in some other compilation unit (relocation truncated to fit: DISP16 against symbol `loopend') -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32738] New: Wrong source file in error message when used from within a macro
https://sourceware.org/bugzilla/show_bug.cgi?id=32738 Bug ID: 32738 Summary: Wrong source file in error message when used from within a macro Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- When a macro has an error, the wrong filename is listed in the error message. Example: foo.S: .include "foo.inc" foo foo.inc: .macro foo nnop .endm When compiling, i get the error: foo.S: Assembler messages: foo.S:2: Error: Unknown operator -- statement `nnop' ignored foo.S:3: Info: macro invoked from here The first message is wrong: line number 4 is that from foo.inc, not foo.S This is independent of the cpu type (except that the error message might be slightly different, eg. "no such instruction") -- You are receiving this mail because: You are on the CC list for the bug.
