[Bug gas/11733] Out of bounds array access prevents build.

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2010-06-21 07:43 --- Subject: Bug 11733 CVSROOT:/cvs/src Module name:src Changes by: amo...@sourceware.org 2010-06-21 07:42:55 Modified files: gas: ChangeLog gas/config : t

[Bug gas/11733] Out of bounds array access prevents build.

--- Additional Comments From amodra at gmail dot com 2010-06-21 08:01 --- Fixed mainline -- What|Removed |Added Status|ASSIGNED|RESOLVED

Re: Fwd: Lost and Wondering

Hi Matthew, Is this the right place for this? Yes. :-) The GNU assembler takes the following instruction (for example): ldreqsh r9, [sl], #0x3f and assembles it to: 0x00da94d0 This is a bug, now fixed. The current version of GAS assembles it to: 00da93ff

[Bug ld/11675] -- oformat binary or srec broken

--- Additional Comments From nickc at redhat dot com 2010-06-21 10:10 --- Hi Vincent, Duh - I wonder why that did not work for me when I tried. Anyway I can now reproduce the problem. It is possible to fix the code in bfd_elf_m68k_set_target_options to avoid the seg-fault, but I t

[Bug ld/11675] -- oformat binary or srec broken

--- Additional Comments From nickc at redhat dot com 2010-06-21 10:11 --- Created an attachment (id=4854) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4854&action=view) Issue an error if an attempt is made to change the output format whilst linking m68k-elf binaries -- htt

[Bug gas/11732] internal error on invalid code && -msyntax=intel

--- Additional Comments From jbeulich at novell dot com 2010-06-21 10:36 --- For what it's worth, the same doesn't abort in 2.20.1. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11732 --- You are receiving this mail because: --- You are on the CC list for the bug, or are

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From schwab at linux-m68k dot org 2010-06-21 11:08 --- That does not work for me. $ cat nopl.s cmove %eax,%edx .align 8 $ as --32 -mtune=i686 nopl.s $ objdump -dr | grep nopl 3: 0f 1f 44 00 00 nopl 0x0(%eax,%eax,1) $ as --32 -mtune=i686 -march=

[Bug gas/11731] -msyntax=intel nasm-incompatible compilation

--- Additional Comments From hjl dot tools at gmail dot com 2010-06-21 14:19 --- (In reply to comment #2) > Actually, masm considers this a syntax error (i.e. doesn't allow dword et al > not > any place a number would be accepted. Kind of confusing, but in any case not a > hint to accep

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From hjl dot tools at gmail dot com 2010-06-21 14:28 --- (In reply to comment #18) > That does not work for me. > > $ cat nopl.s > cmove %eax,%edx > .align 8 > $ as --32 -mtune=i686 nopl.s > $ objdump -dr | grep nopl >3: 0f 1f 44 00 00 nopl 0x

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From schwab at linux-m68k dot org 2010-06-21 14:48 --- I want that the assembler does not sneak in nopl. -- What|Removed |Added Status|WA

Re: Fwd: Lost and Wondering

Thank you, Nick. Much appreciated. Does the assembler allow for both ldrsheq and ldreqsh? (the latter version is what the ARM docs indicate). When will I be able to get a canned version of the updated tool-chain? Thanks, Matt On Monday, June 21, 2010 05:53:21 am Nick Clifton wrote: > Hi Matt

Re: Fwd: Lost and Wondering

Hi Matt, Does the assembler allow for both ldrsheq and ldreqsh? (the latter version is what the ARM docs indicate). Nope, just ldreqsh. When will I be able to get a canned version of the updated tool-chain? The fix is in the latest binutils release (v2.20), so you can get that from wher

[Bug gas/11731] -msyntax=intel nasm-incompatible compilation

--- Additional Comments From jbeulich at novell dot com 2010-06-21 15:32 --- (In reply to comment #5) > When does MASM treat BYTE, WORD, DWORD, ... as numbers? As operands to most operators (or as an expression on their own), but apparently not (generally) to []. Beyond that, as with ot

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From hjl dot tools at gmail dot com 2010-06-21 15:53 --- (In reply to comment #20) > I want that the assembler does not sneak in nopl. Then you should use -mtune=i586 or an option not to tune for i686. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6957 -

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From schwab at linux-m68k dot org 2010-06-21 16:01 --- But the docs say that -mtune only uses non-generic insns when -march is also given. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6957 --- You are receiving this mail because: --- You are on t

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From hjl dot tools at gmail dot com 2010-06-21 16:03 --- -mtune uses all available instructions. By default, all instructions are enabled. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6957 --- You are receiving this mail because: --- You are on t

[Bug gas/6957] i386 NOPs must be derived from march not mtune

--- Additional Comments From schwab at linux-m68k dot org 2010-06-21 16:37 --- nopl is not always available on i686. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6957 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someon

[Bug gas/11728] Output file present even after gas exits with an error

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2010-06-21 23:56 --- Subject: Bug 11728 CVSROOT:/cvs/src Module name:src Changes by: sterl...@sourceware.org 2010-06-21 23:56:34 Modified files: gas: ChangeLog as.c Log message: