Forgetting to this causes unexpected control flow transfers and even
misoptimizations. When building with LLVM 20.1.4 and LTO enabled,
misoptimizations will ultimately lead to segfaults in
dwarf2_gen64_test.sh.
Signed-off-by: Yao Zi <ziyao@disroot.org>
This fixes the following compiler warnings with clang
tools/genperf/perfect.c:65:6: warning: a function definition without a prototype
is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
frontends/yasm/yasm.c:1379:23: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
modules/objfmts/elf/elf.c:225:18: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
This fixes the following compiler error in macOS in CI.
libyasm/tests/bitvect_test.c:112:5: error: implicit declaration of
function 'yasm_xfree' [-Werror,-Wimplicit-function-declaration]
yasm.c: Added -MD, -MT and -MP options similar to gcc. Also added --makedep-dos2unix-slash for helping users of NUG make (and similar) on Windows. The -MD option does both assembling and Makefile dependency generation in one go, which convenient and a little quicker.
nasm-preproc.c: Have to always gather dependencies to support -MD. Minimal cost.
Co-authored-by: knut st. osmundsen <bird-skylake@anduin.net>
Support for "private_extern" was previously added for nasm mode via
a declaration like so:
global foo:private_extern
foo:
; codes
However, that same code in gas format looks like this:
.private_extern foo
foo:
# codes
Add support for the gas version of "private_extern" syntax by
supporting a new gas `.private_extern` directive that actually
has exactly the same semantics as the nasm `global ...:private_extern`
directive.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Prior to this change: cpu_lcd(['AVX'], ['AVX','AES']) == ['AVX'],
causing AES instructions to be treated as unsupported when "cpu
WESTMERE" is used, or even "cpu WESTMERE AES".
Fixed by reordering ordered_cpu_features such that now,
cpu_lcd(['AVX'], ['AVX','AES']) == ['AES']. I don't know if there are
CPUs this would not be correct for, but this is the value that's
consistent with all extant CPU definitions.
This replaces _MSC_VER macro with _WIN32 because the
former one is for MSVC and Visual Studio only and is
not defined in mingw environment. Wherease, _WIN32
macro is the proper way to check Windows platform
irrespective of compiler toolchain.
See the following official link for more info
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros
