The implicit operand size override code didn't set the operand size
prefix, which confused the size calculation code for the range check.
The BITS 64 operand size calculation is still off, but "fixing" it by
making it 32-bit unless REX.W is set breaks PUSH and maybe others.
calcsize() had the wrong criterion for when C5 prefixes are permitted
(REX.R is permitted, REX.X is forbidden.) assemble() had the right
test already. This caused symbol value errors.
H. Peter Anvin pointed
|
| Btw, test/imm64.asm needs test engine annotations.
|
Make it so.
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Two fixes:
1. Optimization of [bx+0xFFFF] etc
0xFFFF is an sbyte under 16-bit semantics,
so make sure to check it right.
2. Don't optimize displacements in -O0
Displacements that fit into an sbyte or
can be removed should *not* be optimized in -O0.
Implicit zero displacements are still optimized, e.g.:
[eax] -> 0 bit displacement, [ebp] -> 8 bit displacement.
However explicit displacements are not optimized:
[eax+0] -> 32 bit displacement, [ebp+0] -> 32 bit displacement.
Because #2 breaks compatibility with 0.98,
I introduced a new optimization level: -OL, legacy.
Under particular circumstances %strlen may cause SIGSEG. A typical
example is %strlen with nonexistent macro argument.
[ Testcase test/strlen.asm ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Allow non-identifier characters in the name of environment variables,
by surrounding them with string quotes (subject to ordinary
string-quoting rules.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add the RD*SBASE, WR*SBASE and RDRAND instructions from version 7 of
the AVX specification, Intel document 319433-007.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The former changes have been committed to binutils.
From initial message:
|
| 2010-03-22 Quentin Neill <quentin.neill@amd.com>
| Sebastian Pop <sebastian.pop@amd.com>
|
| opcodes/
| * i386-dis.c (OP_LWP_I): Removed.
| (reg_table): Do not use OP_LWP_I, use Iq.
| (OP_LWPCB_E): Remove use of names16.
| (OP_LWP_E): Same.
| * i386-opc.tbl: Removed 16bit LWP insns. 32bit LWP insns
| should not set the Vex.length bit.
| * i386-tbl.h: Regenerated.
|
| gas/
| * testsuite/gas/i386/x86-64-lwp.s: Remove use of 16bit LWP insns.
| * testsuite/gas/i386/lwp.s: Same.
| * testsuite/gas/i386/x86-64-lwp.d: Updated.
| * testsuite/gas/i386/lwp.d: Updated.
|
So there is no 16 bit instructions anymore.
Also xop.l field should be set to 0.
Based on patch from nasm64developer
Reported-by: nasm64developer
Signed-off-by: nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Check if the offset and the representation are equivalent.
Disallow REL on absolute addresses.
I'm not sure what that would mean and the output formats don't support it.
Warn about ignored displacement size modifiers.
Unify the token-pasting code between the macro expansion and the
preprocessor parameter case. Parameterize whether or not to handle %+
tokens during expansion (%+ tokens have late binding semantics.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
"+" can be a separate token that ends up having to get pulled into the
middle of a floating-point constant. It's not even that strange.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Especially when token pasting involves floating-point numbers, we can
have some really strange effects from token pasting: for example,
pasting the two tokens "xyzzy" and "1e+10" ends up with *three*
tokens: "xyzzy1e" "+" "10". The easiest way to deal with this is to
explicitly combine the string and then run tokenize() on it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
