https://sourceware.org/bugzilla/show_bug.cgi?id=16490
Michael Zolotukhin changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org
|michael.v.zolotukhin@gmai
https://sourceware.org/bugzilla/show_bug.cgi?id=16489
Michael Zolotukhin changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org
|michael.v.zolotukhin@gmai
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: michael.v.zolotukhin at gmail dot com
Disp8 encoding/decoding is wrong for the following example (supposedly,
encoding is correct, decoding is incorrect):
.intel_syntax noprefix
tatus: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: michael.v.zolotukhin at gmail dot com
GAS doesn't complain about the following insns (depending on operand-check flag
it should emit err
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: michael.v.zolotukhin at gmail dot com
Currently, gas emits error on the following insn:
vscatterqps [eax]{k1}, ymm0
(And similar cases with gather).
But there is
http://sourceware.org/bugzilla/show_bug.cgi?id=13084
--- Comment #6 from Michael Zolotukhin
2012-09-23 15:17:07 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > If working with 64-bit values is incorrect in x32-mode, then we also need to
> > fix tests from gas/i386/ilp32/x
http://sourceware.org/bugzilla/show_bug.cgi?id=13084
--- Comment #4 from Michael Zolotukhin
2012-09-23 14:21:16 UTC ---
If working with 64-bit values is incorrect in x32-mode, then we also need to
fix tests from gas/i386/ilp32/x86-64.s - as they are mostly copied from 64-bit
tests, they c
||gmail dot com
--- Comment #2 from Michael Zolotukhin
2012-09-23 13:26:40 UTC ---
What is expected output for x32 case?
Should AS produce 64-bit symbols or should it emit an error (like it should do
in 32-bit case)?
--
Configure bugmail
