[Bug gas/11395] gas creates 64bit add-instruction in 32bit mode for hppa2.0
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2010-04-16 11:21 --- Subject: Bug 11395 CVSROOT:/cvs/src Module name:src Changes by: ni...@sourceware.org2010-04-16 11:20:41 Modified files: gas: ChangeLog gas/config : tc-hppa.c gas/testsuite : ChangeLog gas/testsuite/gas/hppa/basic: add2.s basic.exp Log message: PR gas/11395 * config/tc-hppa.c (pa_ip): Do not allow 64-bit add condition matcher to accept and unconditional 32-bit add instruction. (pa_build_unwind_subspace): Cope with error conditions not allowing the start symbol to be set. * gas/hppa/basic/add2.s: Add test of simple 32-bit instruction. * gas/hppa/basic/basic.exp (do_add2): Add grep for expected disassembly. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=srcr1=1.4131r2=1.4132 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-hppa.c.diff?cvsroot=srcr1=1.147r2=1.148 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=srcr1=1.1655r2=1.1656 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/hppa/basic/add2.s.diff?cvsroot=srcr1=1.2r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/hppa/basic/basic.exp.diff?cvsroot=srcr1=1.13r2=1.14 --- Additional Comments From nickc at redhat dot com 2010-04-16 11:23 --- Hi Michael, Sorry for taking so long to look at this problem. It turns out to be a bug in GAS's code for parsing condition prefixes for 64-bit addition instructions. If there were no conditions at all the instruction was being matched and treated as a 64-bit add, instead of being rejected and allowing the parser to proceed to the 32-bit add pattern. I have checked in a patch to fix this, as well as an addition to the HPPA part of the GAS testsuite to make sure that the bug stays fixed. Cheers Nick -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=11395 --- 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
Untranslated strings in readelf.c
Hello,
Several untranlated strings exist in binutils 2.20 in function
process_mips_specific of readelf.c. In particular around this place:
10048 printf (_( Reserved entries:\n));
10049 printf (_( %*s %10s %*s Purpose\n),
10050 addr_size * 2, Address, Access,
10051 addr_size * 2, Initial);
10052 entry = print_mips_got_entry (data, pltgot, entry);
10053 printf ( Lazy resolver\n);
10054 if (data
10055(byte_get (data + entry - pltgot, addr_size)
10056(addr_size * 8 - 1)) != 0)
10057 {
10058 entry = print_mips_got_entry (data, pltgot, entry);
10059 printf ( Module pointer (GNU extension)\n);
10060 }
10061 printf (\n);
10062
10063 if (entry local_end)
10064 {
10065 printf (_( Local entries:\n));
10066 printf (_( %*s %10s %*s\n),
10067 addr_size * 2, Address, Access,
10068 addr_size * 2, Initial);
Note the missing _() around Address, Access and Initial in the two
printf.
Frederic
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/11507] New: altmacro: wrong string interpretation
On the macro below 'as' prints infinite number of the following error message test.S:3: Error: `' was already used as parameter (or another local) name .altmacro .macro ABC .print local .endm ABC It's perhaps about that the interpreter thinks the local word in the string of .print is an altmacro directive and as such it has to be carried out. Note, there is a space after local. I've experienced this behavior with binutils 2.18, 2.19, 2.20 on 64-bit and 32-bit gentoo linux as well as on windows xp in cygwin environment (binutils 2.19 and 2.20) -- Summary: altmacro: wrong string interpretation Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: theorizer at freemail dot hu CC: bug-binutils at gnu dot org GCC build triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin GCC host triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin GCC target triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin http://sourceware.org/bugzilla/show_bug.cgi?id=11507 --- 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/11509] New: Strange evaluation of symbol containing register
Assume the source below: .intel_syntax noprefix .eqv param, ebp-4 mov eax, [param] mov eax, [param] On this source 'as' (2.19, 2.20) assembles the following: 0: 8b 45 fcmoveax,DWORD PTR [ebp-0x4] 3: b8 fc ff ff ff moveax,0xfffc 'as' 2.18 however assembles this here: 0: 8b 01 moveax,DWORD PTR [ecx] 2: 8b 01 moveax,DWORD PTR [ecx] if you change the symbol definition line to .eqv param, ebp then the assembled code is already the same for both mov instructions (with any 'as' versions): 0: 8b 45 00moveax,DWORD PTR [ebp+0x0] 3: 8b 45 00moveax,DWORD PTR [ebp+0x0] As I see it does not matter whether you apply .eqv, .equ, .equiv, or =. The result is always the same. -- Summary: Strange evaluation of symbol containing register Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: theorizer at freemail dot hu CC: bug-binutils at gnu dot org GCC build triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin GCC host triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin GCC target triplet: x86_64-gentoo-linux, x86_32-gentoo-linux, cygwin http://sourceware.org/bugzilla/show_bug.cgi?id=11509 --- 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
