For the benefit of those platforms which have to rely on VPATH, avoid
having the same filename in multiple subdirectories.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
All the 16 AMX-TRANSPOSE instructions were removed from the 59th
edition of "Intel Architecture Instruction Set Extensions and Future
Features Programming Reference" September 2025, 319433-059.
Similar to PCOMMIT, they are tagged as 'NEVER'
[ hpa: don't remove from tests, but suppress the warnings. Don't
remove the CPUID tag; a future version of NASM will actually implement
CPU filtering based on the various CPUID tags; that development is
genuinely in progress. ]
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Use autoconf to find either python3 or python.
Add option to travis to filter the contents of stdout or stderr.
Generate the _version.stdout travis matching file from the version
file.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
-- AMX instruction fixes
-- AMX test file extension with new levels
according to Intel ISA Extension Guide 58th edition
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Make the spellings for the label-mangling options and pragmas
consistent, and implement the directive forms which were documented
but never implemented.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The shift and rotate patterns are "interesting" in the following way:
1. Even though only 4/5/6 bits of the input are ever used, for the
regular instructions the input is specified as the CL register, but
for the -X instructions as a size-matching register. This makes the
optimization patterns "interesting."
2. The sequencing of legacy, VEX -X versions, APX EVEX, and APX -X
For #1, allow any size register to contain the shift count.
For #2, split up the macro generation of the patterns, and add a new
"$xmacro" macro to deal with the combinatorics of generating all the
-X patterns. Written directly in Perl since it seemed easier than
trying to make anything more general for what is very much a special
case...
Reported-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Most instructions support contracted forms, but those had been overlooked.
Signed-off-by: Henrik Gramner <henrik@gramner.com>
[ hpa: manual merge ]
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The rounding specifier should be applied to src2, not src1.
Furthermore, VCVTSI2SD with a 32-bit source operand does not
support specifying a rounding mode (as no rounding can occur).
Signed-off-by: Henrik Gramner <henrik@gramner.com>
[ hpa: manual merge ]
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
"suffix" is the more common English term, but NASM used "postfix" for
a long time. Allow them as aliases, and tidy up the documentation
accordingly. While making these changes, tidy up the handling of
options in the index.
Fixes: https://github.com/netwide-assembler/nasm/pull/61
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
According to the June edition of SDM evex-form of the VCVTPS2PH command only exists with mmmmm equal to 0f38, and map5 only exists for the VCVTPS2PHX command
It is somewhat counterintuitive, but the correct flag for the memory
operand is "OSIZE". The "nw" flag takes care of promoting the default
operand size on 64 bits to 64.
Fixes: https://github.com/netwide-assembler/nasm/issues/130
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Quick and easy way to run the same test for 16-, 32- and 64-bit output
without mixing them together in one binary output file.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This is really just a shorthand for the --before option, but it is
really convenient for quickly writing multimode tests.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Generalize pp_pre_command() so that the first argument doesn't have to
be a preprocessor token. Instead, the two arguments are now both
turned into token streams, separated by a whitespace token.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Although one can implement this "manually" in terms of %sel(), this
function is *really* useful for making multi-mode tests and allows for
better error checking.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If an instruction triggers an error (nasm_nonfatal) it is legitimate
for calcsize() to return 0; in that case no further processing is
needed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The label-orphan warning is *way* more useful if it includes the
actual label name; this way the programmer can usually spot
immediately if it is a label or misspelled instruction.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The bugs were found by Svace static analysis tool:
1. sym can be null in when exact is false, and sym is later dereferenced
by sym->symnum
2. asym can be null, no return from function is performed, and asym is
dereferenced by asym->symnum
When compiled -fsanitize=undefined nasm produced this error message:
asm/preproc.c:2523:25: runtime error: member access within null pointer of type 'struct Token'
The problem is reproducible on tests avx512f, avx512cd, avx512pf
and avx512er in the test suite.
The problematic line was:
/* Advance to the next comma */
maybe_comma = &t->next; <<< HERE
while (tok_isnt(t, ',')) {
if (!tok_white(t))
comma = NULL; /* Non-empty parameter */
maybe_comma = &t->next;
t = t->next;
}
When t is NULL this line doesn't cause memory access, but it is still an
undefined behavior according to C standard.
I believe that the underlying problem is that this loop doesn't have a sound
invariant about maybe_comma:
* On first iteration: *maybe_comma == t->next
* On the following iterations: *maybe_comma == t
I don't know what the intended loop invariant is and I decided to just
mechanically fix the deferencing of NULL pointer, completely preserving
the existing behavior.
Signed-off-by: Ivan Sorokin <vanyacpp@gmail.com>
When running with -fsanitize=leak enabled nasm prints this error:
==19965==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 360 byte(s) in 90 object(s) allocated from:
#0 0x7faee9396867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x5645d39a401c in nasm_malloc nasmlib/alloc.c:55
#2 0x5645d3a41f9d in string_transform asm/strfunc.c:356
#3 0x5645d3a37d40 in eval_strfunc asm/eval.c:761
#4 0x5645d3a37d40 in expr6 asm/eval.c:906
#5 0x5645d3a3968d in expr5 asm/eval.c:627
#6 0x5645d3a39aca in expr4 asm/eval.c:602
#7 0x5645d3a39b72 in expr3 asm/eval.c:563
#8 0x5645d3a39db8 in expr2 asm/eval.c:537
#9 0x5645d3a39f38 in expr1 asm/eval.c:511
#10 0x5645d3a3a0b8 in expr0 asm/eval.c:485
#11 0x5645d3a3a242 in rexp3 asm/eval.c:422
#12 0x5645d3a3a508 in rexp2 asm/eval.c:396
#13 0x5645d3a3a6a8 in rexp1 asm/eval.c:369
#14 0x5645d3a3a838 in rexp0 asm/eval.c:342
#15 0x5645d3a3a838 in cexpr asm/eval.c:305
#16 0x5645d3a3ad08 in bexpr asm/eval.c:298
#17 0x5645d3a3ad08 in evaluate asm/eval.c:1032
#18 0x5645d39e4f20 in parse_line asm/parser.c:959
#19 0x5645d399e243 in assemble_file asm/nasm.c:1735
#20 0x5645d3998801 in main asm/nasm.c:719
#21 0x7faee8aaed8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#22 0x7faee8aaee3f in __libc_start_main_impl ../csu/libc-start.c:392
#23 0x5645d399acd4 in _start (/home/ivan/d/nasm/nasm+0x2e5cd4)
SUMMARY: AddressSanitizer: 360 byte(s) leaked in 90 allocation(s).
This problem is reproducible on test utf.asm.
The problem was caused by the fact that eval_strfunc doesn't free the string
allocated by string_transform.
Signed-off-by: Ivan Sorokin <vanyacpp@gmail.com>
The list_last() macro is a statement macro; wrap it in a
do { ... } while(0) block to prevent accidental misuse.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
[ hpa: only one of the defined issues was valid, removed the rest. ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
