[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 : tc-sh.c Log message: PR gas/11733 * config/tc-sh.c (find_cooked_opcode): Correct array bounds check. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.4172&r2=1.4173 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-sh.c.diff?cvsroot=src&r1=1.137&r2=1.138 -- What|Removed |Added AssignedTo|unassigned at sources dot |amodra at gmail dot com |redhat dot com | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2010-06-21 08:00:59 date|| http://sourceware.org/bugzilla/show_bug.cgi?id=11733 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=11733 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
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: 00da93ffldrsheq r9, [sl], #63 ; 0x3f Please help? Which is accurate? Should I trust the assembler, which is responsible for the actual driving of the processor? or the documentation which is the Bible of ARM? In this case always trust ARM's documentation. If there is a discrepancy it is the assembler, or possibly the disassembler, that is to blame. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 think that this is the wrong approach. Essentially the m68k-elf code in the BFD library needs some special fields in the global info structure and these are only created if the output format is m68k-elf. So it is not possible to link m68k-elf binaries and change the output format at the same time. (This restriction is common to quite a few linker targets). So instead I am proposing the uploaded patch to issue an error if an attempt is made to link m68k-elf binaries and change the output format at the same time. What do you think ? Cheers Nick -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=11675 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 -- http://sourceware.org/bugzilla/show_bug.cgi?id=11675 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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=i486 nopl.s nopl.s: Assembler messages: nopl.s:1: Error: `cmove' is not supported on `i486' There should be a way to set -mtune while letting -march alone. -- What|Removed |Added CC||schwab at linux-m68k dot org Status|RESOLVED|REOPENED Resolution|WORKSFORME | 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 someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 accept this (unconditionally) the way nasm would accept it. So at best > this could be controlled by an extra command line and/or .intel_syntax option. When does MASM treat BYTE, WORD, DWORD, ... as numbers? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11731 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 0x0(%eax,%eax,1) > $ as --32 -mtune=i686 -march=i486 nopl.s > nopl.s: Assembler messages: > nopl.s:1: Error: `cmove' is not supported on `i486' > > There should be a way to set -mtune while letting -march alone. Please state exactly what you have in mind. From $ cat nopl.s cmove %eax,%edx .align 8 you want i686 instructions, but you don't want to tune for i686. Is that correct? -- What|Removed |Added Status|REOPENED|WAITING 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 someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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|WAITING |NEW Last reconfirmed|-00-00 00:00:00 |2010-06-21 14:48:07 date|| 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 someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
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 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: > > 00da93ffldrsheq r9, [sl], #63 ; 0x3f > > > Please help? Which is accurate? Should I trust the assembler, > > which is responsible for the actual driving of the processor? > > or the documentation which is the Bible of ARM? > > In this case always trust ARM's documentation. If there is a > discrepancy it is the assembler, or possibly the disassembler, that is > to blame. > > Cheers >Nick > > > -- Matthew Carpenter m...@inguardians.com http://www.inguardians.com PGP Fingerprint: 87EB 54A8 FB42 0A0E B8AE CDA7 FF99 2A64 E70F 4466 hkp://wwwkeys.pgp.net ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
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 wherever you normally get binary packages. You could also download the latest sources and build your own linker. The sources are linked to from the official web site: http://www.gnu.org/software/binutils/binutils.html Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 other things 32- and 64-bit MASM aren't consistent (64-bit e.g. doesn't accept mov eax, [byte] but does accept mov eax, [word+byte] whereas 32-bit accepts both). -- http://sourceware.org/bugzilla/show_bug.cgi?id=11731 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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 someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[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: 2010-06-21 Sterling Augustine PR gas/11728 * as.c: Globalize keep_it. (main): Remove keep_it. Move conditional from here... (close_output_file): ...to here. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.4174&r2=1.4175 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/as.c.diff?cvsroot=src&r1=1.88&r2=1.89 --- Additional Comments From sterling at tensilica dot com 2010-06-21 23:57 --- Patch committed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=11728 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
