[Bug gas/10856] [2.20 regression] gas creates wrong code which results in a test failure in libcrypto++'s sha2 test
--- Additional Comments From gingold at adacore dot com 2009-12-14 09:04 --- Subject: Re: [2.20 regression] gas creates wrong code which results in a test failure in libcrypto++'s sha2 test On Dec 13, 2009, at 6:55 PM, david-sarah at jacaranda dot org wrote: --- Additional Comments From david-sarah at jacaranda dot org 2009-12-13 17:55 --- Any indication of when this fix is likely to get into a release? The more OS distributions as 2.20 goes into, the more problems this bug will cause. I agree that this is annoying. What about a 2.20.1 release in January ? Tristan. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10856 --- 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: [Bug gas/10856] [2.20 regression] gas creates wrong code which results in a test failure in libcrypto++'s sha2 test
On Dec 13, 2009, at 6:55 PM, david-sarah at jacaranda dot org wrote: --- Additional Comments From david-sarah at jacaranda dot org 2009-12-13 17:55 --- Any indication of when this fix is likely to get into a release? The more OS distributions as 2.20 goes into, the more problems this bug will cause. I agree that this is annoying. What about a 2.20.1 release in January ? Tristan. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/11086] build failed
--- Additional Comments From nickc at redhat dot com 2009-12-14 11:01 --- Hi Yoshinori-san, Thanks for reporting this bug and supply the fix. I have applied your patch along with the changelog entry below. Cheers Nick gas/ChangeLog 2009-12-14 Yoshinori Sato ys...@users.sourceforge.jp PR gas/11086 * config/tc-rx.c (rx_equ): Rename 'expr' to 'expression' in order to avoid shadowing a global symbol of the same name. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=11086 --- 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
ld crash (target x86_64-w64-mingw32 mutilib gcc)
Hi I just compiled today's binutils and find it crash at link. ccache x86_64-w64-mingw32-gcc -m32 -o lua.exe -s lua.o lua51.dll -lm collect2: ld terminated with signal 11 [Segmentation fault] GNU ld (GNU Binutils) 2.20.51.20091214 ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-12-14 16:38 --- Subject: Bug 10924 CVSROOT:/cvs/src Module name:src Changes by: ni...@sourceware.org2009-12-14 16:38:23 Modified files: opcodes: ChangeLog arm-dis.c gas/testsuite : ChangeLog Added files: gas/testsuite/gas/arm: unpredictable.d unpredictable.s Log message: PR binutils/10924 * arm-dis.c (arm_opcodes): Specify %R in cases where using r15 results in unpredictable behaviour. (print_insn_arm): Handle %R. * gas/arm/unpredictable.s: New test case - checks the disassembly of instructions with unpredictable behaviour. * gas/arm/unpredictable.d: New file - expected disassembly. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ChangeLog.diff?cvsroot=srcr1=1.1517r2=1.1518 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/arm-dis.c.diff?cvsroot=srcr1=1.117r2=1.118 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=srcr1=1.1603r2=1.1604 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/unpredictable.d.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/unpredictable.s.diff?cvsroot=srcr1=NONEr2=1.1 -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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 binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From nickc at redhat dot com 2009-12-14 16:39 --- Created an attachment (id=4467) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4467action=view) More tests for unpredictable instructions -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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 binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From nickc at redhat dot com 2009-12-14 16:46 --- Hi Chris, I have checked in another patch (which should be in tomorrow's tarball) to fix the new cases you found and also to correct the snafu when post indexed addressing is used with an immediate offset 15. (The code was checking for a register number of 15, but forgot to see if register-indexed or immediate-indexed addressing was being used). I have also added a new testcase to the gas testsuite for the ARM, to check the disassembly of unpredictable instructions. One thing I found whilst doing this is that there are several instructions that GAS itself will happily assemble, even though they have unpredictable behaviour. (Eg mrs pc, cpsr). So I guess I am going to have to start fixing gas as well. *sigh* There are also several situations where unpredictable behaviour results from the same register being used twice in an instruction. (Eg the MLA, MUL, UMULL etc instructions). Currently the disassembler does not pick these up. I am not sure how important it is to detect them, but let me know what you think. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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/11088] Internal Error in ppc64_elf_gc_sweep_hook
--- Additional Comments From amodra at bigpond dot net dot au 2009-12-14 23:40 --- I'd like to know why we have the failure before you apply your patch, Nick. Especially since there's a similar ppc32 report but no testcase. In looking over the ppc32 code I found a number of problems with handling of pltrel24 relocs but nothing that might cause a failure in gc_sweep_hook. :-( -- http://sourceware.org/bugzilla/show_bug.cgi?id=11088 --- 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 binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-15 02:20 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Mon, Dec 14, 2009 at 04:46:12PM -, nickc at redhat dot com wrote: There are also several situations where unpredictable behaviour results from the same register being used twice in an instruction. (Eg the MLA, MUL, UMULL etc instructions). Currently the disassembler does not pick these up. I am not sure how important it is to detect them, but let me know what you think. I'm not sure what you mean. Are you saying you don't want to flag all UNPREDICTABLES? I would think we should flag all UNPREDICTABLEs with a comment. It helps me check objdump against by custom disassemblerI need something in the output that is predictable. Did you catch all the load and store situations that are UNPREDICTABLE when the same register is used twice I alerted you to in a previous email? Chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- 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
