S_ISREG() is usually a macro, it needs PA_HAVE_FUNC().
Don't bother checking for functions related to struct _stati64 if that
definition doesn't exist.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The POSIX names for these functions are htole*(). Use those
preferentially.
Speed up autoconf by allowing early-out during alternative function
searches.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The last testcase hangs the travis test system. The cfcmovb rv rv syntax
seems to cause problems for some reason.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Add a very long list of tests checking most combinations of this
instruction syntax.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
The encodings of 'true' and 'false' variants of the CCMPSCC instructions
were swapped. Correct that in the preprocessor script.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Add database entries and test cases for WRSSD, WRSSQ, WRUSSD and WRUSSQ
instructions.
Fix whitespace in legacy database entries.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Older versions of NASM would not try to match unknown %if directives
with a corresponding %endif, resulting in some very odd consequences
when it comes to trying to handle support for multiple NASM versions.
Document the problem.
Reported-by: E. C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If an unknown preprocessor directive starting with %if or %elif is
encountered, assume it should be treated as a conditional directive
for the purpose of balancing %if...%endif.
This avoids some really ugly problems when dealing with code that is
intended to work across NASM versions that uses %if directives that
don't yet exist.
Reported-by: E. C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The intended form was __?NASM_HAS_IFDIRECTIVE?__, which matches the
documentation but not the code. Fix the code.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The message-generating functions appear to get expanded when they
shouldn't, resulting in errors. Disable them for now and remove them
from the documentation.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add the %find() and %findi() functions to look for a string in a
list. This is useful with picking apart the contents of the
__?DEFAULT?__ macro, for example.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Create a __?DEFAULT?__ magic macro with the settings of the DEFAULT
directive.
The DEFAULT directive is complex enough that this is best done with a
magic macro.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Making DEFAULT ABS the default for 64-bit mode was a real
mistake. Issue a warning so we can eventually change it.
Support making FS: and GS: references also be REL by default.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The %exitmacro directive was never documented, apparently...
Reported-by: E. C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change 3.0 to 3.00 in all version numbers, since NASM has
traditionally expanded all but the major version number to 2 digits.
Make the language related to __?NASM_HAS_IFDIRECTIVE?__ more
consistent.
Reported-by: E. C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If the shift amount is known, there is really no reason why we can't
accept "ROLX" as an alias for "RORX" with a modified shift operand.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
These are subtle: RORX is only available in immediate shift count
form, whereas SHLX, SHRX and SARX are only available in register shift
count form...
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add database entries and test cases for TILELOADD, TILELOADDT1,
TILELOADDRS, TILELOADDRST1 and TILESTORED.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Add database entries for SHLX, SARX and SHRX (APX and non-APX). Add
tests to the newly added instructions.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
