[Bug gas/20318] New: x86 Intel mode accepts invalid instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20318 Bug ID: 20318 Summary: x86 Intel mode accepts invalid instructions Product: binutils Version: 2.27 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jbeulich at novell dot com Target Milestone: --- Created attachment 9373 --> https://sourceware.org/bugzilla/attachment.cgi?id=9373&action=edit small set of examples The attached example demonstrates this for a small subset: The stripping of suffixes results in the assembler being pretty lax. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20318] x86 Intel mode accepts invalid instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20318 --- Comment #2 from Jan Beulich --- Not sure what you're trying to tell me here: The title clearly says this is an issue in Intel mode only. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20318] x86 Intel mode accepts invalid instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20318 Jan Beulich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Beulich --- Commit 83b16ac694. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/707] intel syntax vs 'fnstcw ' and 'fldcw'
--- Additional Comments From jbeulich at novell dot com 2005-02-08 13:47 --- Patch at http://sources.redhat.com/ml/binutils/2005-02/msg00118.html -- What|Removed |Added Status|NEW |ASSIGNED GCC build triplet|i685-pc-mingw32 |i686-pc-mingw32 GCC host triplet|i685-pc-mingw32 |i686-pc-mingw32 GCC target triplet|i685-pc-mingw32 |i686-pc-mingw32 http://sources.redhat.com/bugzilla/show_bug.cgi?id=707 --- 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/707] intel syntax vs 'fnstcw ' and 'fldcw'
--- Additional Comments From jbeulich at novell dot com 2005-02-09 08:06 --- patch committed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=707 --- 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/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-15 12:24 --- I see two problems with this suggestion: The small one is that the change to read.c isn't shown. The larger one is that I don't think this is the right thing to do here. tc_canonicalize_symbol_name shouldn't be called in this context at all; even for non-zero length symbols it may do the wrong thing (for ia64 it removes trailing # symbols), whereas file names should remain untouched. Looking at how this gets called here, I see that save_symbol_name may do more bad to the filename (it may strip a leading _, and may also case-convert it). So it could either be save_symbol_name (or symbol_new) that would need to change (taking an additional parameter to indicate it should leave alone the symbol name), or elf_file_symbol would have to change the name of the symbol after having gone through symbol_new (and to address the problem brought up here, it could call symbol_new blindly with a literal string [say, "FILE"], preventing any issues with tc_canonicalize_symbol_name). -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- 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/848] gas testsuite FAIL: macros dot
--- Additional Comments From jbeulich at novell dot com 2005-04-15 13:34 --- This is more wide-spread, other affected targets are hppa, ns32k, and vax. Slightly different reasons cause d30v, dlx, i860, and or32 to fail. For these, the testcase output expectation needs to be adjusted; I have a tentative patch to do so. There may be more, but many targets currently don't build (due to -Werror). -- What|Removed |Added CC||jbeulich at novell dot com http://sources.redhat.com/bugzilla/show_bug.cgi?id=848 --- 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/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-15 15:26 --- Rejecting zero-length symbols could be undone, but I don't see the point; namely I can't see how you would ever use such a symbol (a standalone # operator is certainly illegal on ia64, and besides that ia64 has .alias to force "odd" symbol names that you can't normally express). Besides that, while addressing this PR, it wouldn't fix the other issue I mentioned. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- 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/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-18 08:48 --- I just submitted a patch to undo the rejecting of zero-length symbol names; however, as said before, while this addresses the immediate issue reported here I continue to believe that stuff like .file "hash#" .file "_underscore" .file "UPPER" .file "lower" all should give consistent entries in the object file's symbol table, no matter what target architecture they're used on. Getting this right, however, requires avoiding save_symbol_name (or undoing its effects), implying avoiding/undoing any treatment tc_canonicalize_symbol_name might apply/have applied. (Alternatively, tc_canonicalize_symbol_name could be given a way to know it's dealing with a file name, so as to allowing it to decide whether do do anthing special here, but I don't think that'd be the right solution; after all, file names only depend on file system conventions, not on processor architecture [leaving aside that certain file systems may only exist on certain architectures]). -- What|Removed |Added Status|NEW |ASSIGNED http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- 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/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-19 07:01 --- ia64-specific patch applied to mainline; awaiting release manager approval for 2.16... -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- 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/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-20 07:52 --- Also applied to 2.16. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- 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/848] gas testsuite FAIL: macros dot
--- Additional Comments From jbeulich at novell dot com 2005-05-06 06:59 --- Both the sparc failure and the ones mentioned in the previous entry being caused by other reasons should be fixed now. None of the other mentioned targets' maintainers reacted, and since they're not the topic of this bug I'm closing it now. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=848 --- 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/941] gas test macros fails
--- Additional Comments From jbeulich at novell dot com 2005-05-09 15:42 --- cross reference: bug #848 -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=941 --- 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/941] gas test macros fails
--- Additional Comments From jbeulich at novell dot com 2005-05-09 15:40 --- Yes, a similar issue was reported against sparc; this needs to be fixed in the hppa code. There was some discussion regarding that on the mailing list, and since a few more targets are affected by this I actually asked the maintainers of those targets to respond and/or fix this. The bottom line is that it is highly questionable practice in these targets to use as_fatal (rather than as_bad) on unrecognized opcodes. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=941 --- 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/1387] New: .equiv may not detect already defined symbol
For example, in .equiv x, y .equiv x, 1 the re-definition is not detected, because x gets associated (in pseudo_set) with undefined_section during the first assignment. -- Summary: .equiv may not detect already defined symbol Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: jbeulich at novell dot com CC: bug-binutils at gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://sourceware.org/bugzilla/show_bug.cgi?id=1387 --- 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/1387] .equiv may not detect already defined symbol
--- Additional Comments From jbeulich at novell dot com 2005-09-29 08:29 --- See also http://sourceware.org/ml/binutils/2005-09/msg00280.html and its follow-ups. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1387 --- 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/288] expression resolved too early
--- Additional Comments From jbeulich at novell dot com 2005-10-20 11:31 --- This should be fixed with http://sourceware.org/ml/binutils/2005-10/msg00112.html. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=288 --- 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/1070] Assembler error: too many positional arguments
--- Additional Comments From jbeulich at novell dot com 2006-02-17 09:58 --- The two patches also break when using macro arguments like m (x)/(y) because parsing stops after the closing parenthesis (another needed difference in behavior from processing of angle brackets). Further, the code is still unable to deal with things like m 1+(2 + 3) Finally, even though I didn't experience problems with that, I would suspect that providing standalone (or otherwise unmatched) parentheses as macro arguments gets broken by this patch. -- What|Removed |Added CC||jbeulich at novell dot com http://sourceware.org/bugzilla/show_bug.cgi?id=1070 --- 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/1387] .equiv may not detect already defined symbol
--- Additional Comments From jbeulich at novell dot com 2006-03-17 08:26 --- This should be resolved with a checkin from 2005-10-27. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=1387 --- 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/3469] GAS encodes corrupt relocation ld reports bad reloc symbol index
--- Additional Comments From jbeulich at novell dot com 2006-11-08 15:07 --- But this is exactly one of these ambiguous cases: While I agree that it shouldn't silently produce a bad object file, what should gas assume the user wants - the first value seen, or the last one (or any intermediate one if there is more than one redefinition)? Maybe it should really be invalid to allow re-defining an equated symbol to anything but another equate. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3469 --- 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/3469] GAS encodes corrupt relocation ld reports bad reloc symbol index
--- Additional Comments From jbeulich at novell dot com 2006-11-13 15:09 --- I would think that symbol_equated_reloc_p() for such a symbol should return true, but it doesn't. Investigating further... -- http://sourceware.org/bugzilla/show_bug.cgi?id=3469 --- 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/3469] GAS encodes corrupt relocation ld reports bad reloc symbol index
--- Additional Comments From jbeulich at novell dot com 2006-11-14 09:38 --- Created an attachment (id=1417) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1417&action=view) tentative patch this one's against 2.17, testing against mainline in progress -- http://sourceware.org/bugzilla/show_bug.cgi?id=3469 --- 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/3469] GAS encodes corrupt relocation ld reports bad reloc symbol index
--- Additional Comments From jbeulich at novell dot com 2006-11-15 11:24 --- patch submitted -- http://sourceware.org/bugzilla/show_bug.cgi?id=3469 --- 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/3469] GAS encodes corrupt relocation ld reports bad reloc symbol index
--- Additional Comments From jbeulich at novell dot com 2006-11-16 08:15 --- patch committed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=3469 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From jbeulich at novell dot com 2007-02-07 15:03 --- The first case must be accepted, since masm allows this as long as the pointer width specified matches the register width. masm fails when the latter isn't true, while gas emit a warning only. I don't think that's a problem, though. As to whether the noprefix handling is correct the way it currently is - that doesn't depend on Intel mode only, as the register parsing logic is, afaics, the same in both AT&T and Intel modes. Generally I would say current behavior is wrong at least in Intel mode, but someone with more profound AT&T syntax knowledge would need to clarify whether this should be changed for both modes or just for Intel. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/4089] GAS allows using 64-bit regs in 32-bit mode (Intel syntax)
--- Additional Comments From jbeulich at novell dot com 2007-02-28 08:25 --- As can be seen from the generated opcode, 'rax' is taken as a symbol name rather than a register here. This is the expected behavior when not using % prefixes for register names. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=4089 --- 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/6517] New: cvtsi2sd and cvtsi2ss with mem operand may fail to assemble
Other than in 2.18, this code
.intel_syntax noprefix
.text
Start:
cvtsi2sd xmm0, [ecx]
cvtsi2ss xmm0, [ecx]
no longer assembles ('ambiguous operand size ...') - the assembler expects a
'dword ptr' operand size specifier, which should only be needed when assembling
64-bit code (where the memory operand can be 32 or 64 bits wide).
--
Summary: cvtsi2sd and cvtsi2ss with mem operand may fail to
assemble
Product: binutils
Version: 2.19 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jbeulich at novell dot com
CC: bug-binutils at gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=6517
--- 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/6517] cvtsi2sd and cvtsi2ss with mem operand may fail to assemble
--- Additional Comments From jbeulich at novell dot com 2008-05-14 12:24 --- This should of course also be adjusted for vcvts12sd/vcvts12ss. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6517 --- 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/6518] New: wrong diagnostic for vcvtpd2dq/vcvtpd2ps/vcvttpd2dq
Rather than reporting 'suffix or operands invalid ...' on all three instructions when there is no operand size specifier on the memory operand, 'ambiguous operand size ...' should be reported - the former message implies that a memory operand may not be used at all here: .intel_syntax noprefix .text Start: vcvtpd2dq xmm0, [ecx] vcvtpd2ps xmm0, [ecx] vcvttpd2dq xmm0, [ecx] -- Summary: wrong diagnostic for vcvtpd2dq/vcvtpd2ps/vcvttpd2dq Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: jbeulich at novell dot com CC: bug-binutils at gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://sourceware.org/bugzilla/show_bug.cgi?id=6518 --- 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/6518] wrong diagnostic for movsx/movzx/vcvtpd2dq/vcvtpd2ps/vcvttpd2dq
--- Additional Comments From jbeulich at novell dot com 2008-05-26 08:47 --- I disagree to this approach of fixing the issue - for one, the existing diagnostic shouldn't become more vague for cases it was precise for so far, and secondly in other cases operand size ambiguity is being reported correctly: .intel_syntax noprefix .text Start: vcvtpd2ps xmm0, [eax] vcvtpd2ps xmm0, xmmword ptr [eax] vcvtpd2ps xmm0, ymmword ptr [eax] movzx eax, [eax] movzx eax, byte ptr [eax] movzx eax, word ptr [eax] add [eax], 1 add byte ptr [eax], 1 add word ptr [eax], 1 add dword ptr [eax], 1 mov [eax], 1 mov byte ptr [eax], 1 mov word ptr [eax], 1 mov dword ptr [eax], 1 You'll note that for movzx the same problem as for the three newly added AVX instructions exists, so this (and then obviously movsx) is another candidate needing proper fixing - it properly showed the "ambiguous operand size" message in 2.18, so I'm afraid this is another regression introduced by some of the large re-work you did (the code is still there, at around tc-i386.c:2700, but presumably isn't being reached anymore). -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|wrong diagnostic for|wrong diagnostic for |vcvtpd2dq/vcvtpd2ps/vcvttpd2|movsx/movzx/vcvtpd2dq/vcvtpd |dq |2ps/vcvttpd2dq http://sourceware.org/bugzilla/show_bug.cgi?id=6518 --- 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 jbeulich at novell dot com 2010-06-21 06:51 --- 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. -- 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/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/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/11806] FAIL: i386 intelbad with -O0
--- Additional Comments From jbeulich at novell dot com 2010-07-12 10:54 --- The error message you quote is certainly right for that line. Also, I cannot reproduce the behavior here. Could you attach the full gas/testsuite/gas.log, or at least the full fragment pertaining to that particular test? -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=11806 --- 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/11806] FAIL: i386 intelbad with -O0
--- Additional Comments From jbeulich at novell dot com 2010-07-12 15:17 --- (In reply to comment #2) > When binutils is compiled with -O0, this error: > > gas/i386/intelbad.s:156: Error: operand type mismatch for `mov' > > doesn't show up. As I said - I do not see this here. Is this perhaps compiler version dependent? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11806 --- 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/12374] New: ld fails to convert global hidden symbols to local ones
http://sourceware.org/bugzilla/show_bug.cgi?id=12374 Summary: ld fails to convert global hidden symbols to local ones Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: jbeul...@novell.com Created attachment 5183 --> http://sourceware.org/bugzilla/attachment.cgi?id=5183 trivial example The version of the spec I have says "A hidden symbol contained in a relocatable object must be either removed or converted to STB_LOCAL binding by the link-editor when the relocatable object is included in an executable file or shared object." Nevertheless I see global hidden symbols in executables. Attaching a trivial sample, to be run through as -o hidden.o hidden.s ld -o hidden hidden.o objdump -t hidden -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12374] ld fails to convert global hidden symbols to local ones
http://sourceware.org/bugzilla/show_bug.cgi?id=12374 Jan Beulich changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Jan Beulich 2011-02-14 08:05:14 UTC --- Indeed, as was clarified on the mailing list. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/14439] New: x86/Intel mode: diagnostics for monitor/mwait operands are issued with wrong operand numbers
http://sourceware.org/bugzilla/show_bug.cgi?id=14439 Bug #: 14439 Summary: x86/Intel mode: diagnostics for monitor/mwait operands are issued with wrong operand numbers Product: binutils Version: 2.23 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sourceware.org ReportedBy: jbeul...@novell.com Classification: Unclassified Since operands get needlessly swapped for these two instructions (other than e.g for the similar invlpga), their numbers aren't reported correctly when incorrect operand usage is being detected. The preferable solution would be to make these instructions match invlpga (i.e. suppress operand swapping), as all of them are inputs only. Alternatively, diagnostic generation would need to be adjusted, or the variants allowing for operands could be disallowed in Intel mode (as the documentation doesn't allow operands here anyway). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/14439] x86/Intel mode: diagnostics for monitor/mwait operands are issued with wrong operand numbers
http://sourceware.org/bugzilla/show_bug.cgi?id=14439 --- Comment #1 from Jan Beulich 2012-08-07 10:58:27 UTC --- A patch to carry out the preferred solution can be found at http://www.sourceware.org/ml/binutils/2012-07/msg00173.html. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/14439] x86/Intel mode: diagnostics for monitor/mwait operands are issued with wrong operand numbers
http://sourceware.org/bugzilla/show_bug.cgi?id=14439 --- Comment #3 from Jan Beulich 2012-08-08 09:35:37 UTC --- (In reply to comment #2) > Can you add ATTsyntax to existing monitor/wait entries and new > ones with Intelsyntax to i386-opc.tbl deal with it? That might be doable, but as indicated on the ml already the only valid solution I see is to not swap the operands for these instructions. I won't implement something that I don't buy off on. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/17421] Internal error in output_insn during kernel build
https://sourceware.org/bugzilla/show_bug.cgi?id=17421 Jan Beulich changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jbeulich at novell dot com Resolution|FIXED |--- --- Comment #8 from Jan Beulich --- As was pointed out in email (https://sourceware.org/ml/binutils/2014-09/msg00204.html), the fix is wrong and should be reverted/adjusted: VEX-encoded instructions are, according to current documentation at least, only unsupported in Real and VM86 modes; 16-bit protected mode is not being listed in section "Exception Conditions for VEX-Encoded GPR Instructions" (and similarly for any of the SIMD ones). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 Jan Beulich changed: What|Removed |Added CC||jbeulich at novell dot com --- Comment #4 from Jan Beulich --- The adjustment done to intelok.s is was wrong here: MASM accepts that code, and so should gas. I certainly can agree that accepting _anything_ between the colons was too lax, but the change has definitely introduced a regression. Please fix, and for future Intel syntax changes please also follow the fundamental model of awaiting maintainer approval. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #5 from Jan Beulich --- (I can't, btw, see how to change the status of the bug back from RESOLVED FIXED, or how to re-assign it. Pretty strange a UI limitation as it seems.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #7 from Jan Beulich --- (In reply to H.J. Lu from comment #6) > If gas doesn't allow multiple segment registers in AT&T syntax, it > shouldn't allow them in Intel syntax. I can only keep telling you that I view maximum possible compatibility with MASM more important that compatibility between the under-specified (or should I say not specified at all) AT&T syntax. As the maintainer of the Intel syntax code I would not have approved the patch in the shape you've committed it. Please fix it to avoid the need to revert. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #9 from Jan Beulich --- (In reply to H.J. Lu from comment #8) > (In reply to Jan Beulich from comment #7) > > (In reply to H.J. Lu from comment #6) > > > If gas doesn't allow multiple segment registers in AT&T syntax, it > > > shouldn't allow them in Intel syntax. > > > > I can only keep telling you that I view maximum possible compatibility with > > MASM more important that compatibility between the under-specified (or > > should I say not specified at all) AT&T syntax. As the maintainer of the > > Intel syntax code I would not have approved the patch in the shape you've > > committed it. Please fix it to avoid the need to revert. > > My understanding is that gas can't assemble many assembly codes which > accept MASM. Of course, hence me saying "maximum possible compatibility" (instead of saying "full"). > It is more important for gas to be consistent with itself. That's a bogus goal imo: Different assembly syntax can naturally result in apparent inconsistencies. > In the case of "fs:gs:[eax]", you can replace it with > "fs:[eax]" to get the same output. In straight line code yes. But what if a first override is hidden deep in a macro you can't or don't want to modify, but you need to add an override to in one special case? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #11 from Jan Beulich --- (In reply to H.J. Lu from comment #10) > > > In the case of "fs:gs:[eax]", you can replace it with > > > "fs:[eax]" to get the same output. > > > > In straight line code yes. But what if a first override is hidden deep in a > > macro you can't or don't want to modify, but you need to add an override to > > in one special case? > > Do you have a real example? No, I don't. But I don't assume you have a real example of someone having used something like fs:foo:[ebx] either, to support your original change. The reporter's example, as he states, did not result in bad code being generated (and for that case accepting the code was the intended behavior). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #15 from Jan Beulich --- (In reply to H.J. Lu from comment #12) > (In reply to Jan Beulich from comment #11) > > (In reply to H.J. Lu from comment #10) > > > Do you have a real example? > > > > No, I don't. But I don't assume you have a real example of someone having > > used something like fs:foo:[ebx] either, to support your original change. > > The reporter's example, as he states, did not result in bad code being > > generated (and for that case accepting the code was the intended behavior). > > Someone bothered enough to open a bug report with a testcase. That is > good enough for me. Do you realize that this doesn't address my comment at all? Someone _claiming_ that an example provided is bad doesn't mean it is bad, the more when the generated code is still matching expectations. If I was to follow what you say, me claiming "fs:gs:[mem]" being rejected now breaks code I'm using somewhere would be "good enough" for you. And really that's what I did (albeit openly admitting that I have no actual use case, but I could easily construct one), yet you continue to refuse fixing your earlier change. The mere fact that there was a loop that you've eliminated should already have given enough of a hint to you that at least certain redundant segment overrides were indeed intended to be permitted. Once again, I'm perfectly fine with invalid code (gs:foo:[mem]) to be properly rejected. I continue to consider gs:fs:[mem] valid code, based on MASM accepting it (for whatever, perhaps historical, reason). Hence, as before, I only see two options here: You fix your change, or I revert it and provide a fix which I consider correct (once I find time for doing so). I think there's little point in me repeating this yet another time, should you continue to reply back with unconvincing arguments. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874
--- Comment #17 from Jan Beulich ---
This is a tentative patch which could replace the bad one. Only tested on
2.29.1 so far.
--- 2.29.1/gas/config/tc-i386-intel.c
+++ 2.29.1/gas/config/tc-i386-intel.c
@@ -411,7 +413,19 @@ static int i386_intel_simplify (expressi
intel_state.index))
return 0;
if (!intel_state.in_offset)
- intel_state.seg = e->X_add_symbol;
+ {
+ if (!intel_state.seg)
+ intel_state.seg = e->X_add_symbol;
+ else
+ {
+ expressionS exp;
+
+ exp.X_op = O_full_ptr;
+ exp.X_add_symbol = e->X_add_symbol;
+ exp.X_op_symbol = intel_state.seg;
+ intel_state.seg = make_expr_symbol (&exp);
+ }
+ }
i386_intel_fold (e, e->X_op_symbol);
break;
@@ -935,7 +964,8 @@ i386_intel_operand (char *operand_string
for (;;)
{
expP = symbol_get_value_expression (intel_state.seg);
- if (expP->X_op != O_full_ptr)
+ if (expP->X_op != O_full_ptr
+ || symbol_get_value_expression (expP->X_op_symbol)->X_op !=
O_register)
break;
intel_state.seg = expP->X_add_symbol;
}
--- 2.29.1/gas/testsuite/gas/i386/inval-seg.l
+++ 2.29.1/gas/testsuite/gas/i386/inval-seg.l
@@ -1,10 +1,22 @@
.*: Assembler messages:
.*:3: Error: .*
.*:4: Error: .*
+.*:7: Error: .*
+.*:8: Error: .*
+.*:9: Error: .*
+.*:10: Error: .*
+.*:11: Error: .*
GAS LISTING .*
- 1 [ ]* .text
- 2 [ ]*# All the following should be illegal
- 3 [ ]* movl%ds,\(%eax\)
- 4 [ ]* movl\(%eax\),%ds
+[ ]*[1-9][0-9]*[ ]*\.text
+[ ]*[1-9][0-9]*[ ]*# All the following should be illegal
+[ ]*[1-9][0-9]*[ ]*movl %ds,\(%eax\)
+[ ]*[1-9][0-9]*[ ]*movl \(%eax\),%ds
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]*\.intel_syntax noprefix
+[ ]*[1-9][0-9]*[ ]*mov eax, es:foo:\[eax\]
+[ ]*[1-9][0-9]*[ ]*mov eax, es:fs:foo:\[eax\]
+[ ]*[1-9][0-9]*[ ]*mov eax, fs:foo:bar:\[eax\]
+[ ]*[1-9][0-9]*[ ]*mov eax, fs:foo:gs:\[eax\]
+[ ]*[1-9][0-9]*[ ]*mov eax, bar:gs:\[eax\]
--- 2.29.1/gas/testsuite/gas/i386/inval-seg.s
+++ 2.29.1/gas/testsuite/gas/i386/inval-seg.s
@@ -2,3 +2,10 @@
# All the following should be illegal
movl%ds,(%eax)
movl(%eax),%ds
+
+ .intel_syntax noprefix
+ mov eax, es:foo:[eax]
+ mov eax, es:fs:foo:[eax]
+ mov eax, fs:foo:bar:[eax]
+ mov eax, fs:foo:gs:[eax]
+ mov eax, bar:gs:[eax]
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #19 from Jan Beulich --- (In reply to H.J. Lu from comment #18) > (In reply to Jan Beulich from comment #17) > > This is a tentative patch which could replace the bad one. Only tested on > > 2.29.1 so far. > > Does GCC behave the same with and without -asm=intel with your change? As long as there's only a single segment override - of course. Obviously multiple (redundant) segment overrides would then be accepted again, as they should be. But as long as gcc cares, it should emit anything like that. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #21 from Jan Beulich --- (In reply to H.J. Lu from comment #20) > MASM is totally irrelevant here. This is your opinion, which I don't share. Is this formally written down anywhere? Plus the presence of a MASM syntax expression parser pretty clearly contradicts this statement of yours. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #23 from Jan Beulich --- (In reply to H.J. Lu from comment #22) > The MASM syntax expression parser supports -masm=intel. How that? The compiler doesn't emit expressions, it does all the calculations and emits plain numbers. Are you perhaps mixing up expressions and things like "dword ptr" specifiers (which aren't themselves expressions)? > At very minimum, a warning should be issued by default, which can be > controlled > by > > -moperand-check=[none|error|warning] I can certainly arrange for that, albeit it's a waste of time (and may defer when I get to submit the replacement patch, while I'll surely revert the original one before the next release bets branched, unless you finally show willingness to fix the regression you've introduced). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #25 from Jan Beulich --- (In reply to H.J. Lu from comment #24) > Please don't do that. Why would I not? As indicated, you didn't obtain maintainer approval. In fact I've just checked the mailing list archives - you didn't even think you would need to, as you've sent the mail (according to its subject) only after the commit. The amount of trouble you give me elsewhere (largely defeating my intention of improving the overall code, using time I could equally well spend on other things), I don't see any reason at all why I shouldn't insist on proper process here. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22441] New: x86-64: wrong relocation type used for 32-bit index-with-no-base addressing
https://sourceware.org/bugzilla/show_bug.cgi?id=22441 Bug ID: 22441 Summary: x86-64: wrong relocation type used for 32-bit index-with-no-base addressing Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jbeulich at novell dot com Target Milestone: --- This piece of code .text .intel_syntax noprefix .global _start _start: ret apic_read: mov eax, [edi*4+APIC_BASE] ret apic_write: mov [edi*4+APIC_BASE], esi ret fails to link (with --defsym APIC_BASE=0xfee0 passed to ld). With the "*4" removed all works fine. Fix already submitted: https://sourceware.org/ml/binutils/2017-11/msg00234.html. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #26 from Jan Beulich --- https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=eb0660c6950e08e44fdfeca3e29320382e2a1554 replaces the original commit. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22441] x86-64: wrong relocation type used for 32-bit index-with-no-base addressing
https://sourceware.org/bugzilla/show_bug.cgi?id=22441 Jan Beulich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jan Beulich --- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=43083a502b8d658b8d096111e54afcc73b0215a4 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22871] Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at novell dot com
--- Comment #1 from Jan Beulich ---
subq %r64, %r64 and testq $imm31, %r64 could similarly benefit. Whether
converting test{q,l,w} $imm8,%r{64,32,16} to testb $imm8,%r8 isn't as clear,
but I think reads of 8-bit registers are commonly not causing stalls (only
writes do).
Along those lines test{q,l,w} $imm,mem might allow conversion if all set bits
in imm fall within a single byte. Of course care needs to be taken that the
adjustment to the displacement won't break addressability of the object.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22871] Encode instructions of 64-bit operand without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 --- Comment #6 from Jan Beulich --- (In reply to H.J. Lu from comment #5) > I updated users/hjl/optimize branch to encode > > testq $imm31, mem > > as > > testl $imm31, mem > > only at -O2. I was about to suggest that, also because the memory access pattern changes (the shorter access may not fault when the longer one would, not to think of side effects when accessing MMIO). I'd even consider moving this higher up, to -O3. Another thing to consider here would be to encode e.g. vxorps %zmmM, %zmmM, %zmmN as vxorps %xmmM, %xmmM, %xmmN for the low 16 registers, as that'll be VEX encodable, i.e. shorter than the default EVEX variant. Same for vandnps (and of course all their flavors dealing with different data types). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22871] Encode instructions of 64-bit operand without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 --- Comment #13 from Jan Beulich --- One more pair of cases to consider is conversion of word/dword/qword add/sub with an immediate of 128 to sub/add with -128 as immediate. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 --- Comment #2 from Jan Beulich --- (In reply to Martin Liška from comment #1) > Fixed in bintuils with: > > commit 629cfaf1b0fbb32a985607c774bd8e7870b9fa94 (HEAD, refs/bisect/bad) > Author: Jan Beulich > Date: Mon Jul 30 17:25:05 2018 +0200 > > x86: don't mistakenly scale non-8-bit displacements I don't understand this comment: Said commit does not add any S/G test case(s) o the testsuite. I don't think you should have copied the respective gcc bug comment here. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24546] x86-64 far jump/call encoding issues
https://sourceware.org/bugzilla/show_bug.cgi?id=24546 Jan Beulich changed: What|Removed |Added CC||jbeulich at novell dot com --- Comment #6 from Jan Beulich --- (In reply to H.J. Lu from comment #5) > That is the reason for the current behavior. But you've introduced the Intel64 and AMD64 attributes, which could be used here as well to distinguish the behavior. Also for LFS, LGS, and LSS then. Similarly conditional branches (including LOOP etc) would want handling to match that of near CALL/JMP afaict. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24546] x86-64 far jump/call encoding issues
https://sourceware.org/bugzilla/show_bug.cgi?id=24546 --- Comment #8 from Jan Beulich --- (In reply to H.J. Lu from comment #7) > Care to make a patch? Well, I've added it to my list of things to look into, but there are various other things higher up that list, so it's not clear at all when I'd fine time. Plus Andrew's and my own observations on the actual behavior appear to disagree, making us suspect for the moment that there might even be model specific behavior (beyond the vendor differences) here. I wouldn't want to pin down one variant in binutils when there potentially are others as well. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
