This reverts commit 1d8c107d49.
After 49e14021be, when using F(-NAN)
instead of -F(NAN) to hide the negation, this test passes correctly.
I hadn't realized that GCC and Clang optimized cos(-x) = cos(x), when
I made 1d8c107d49 (and at the time, the
F() macro didn't work properly with -NAN on all toolchains).
In the former form, the negation of NAN is hidden inside the
optimization blocking macro/wrapper. After
9be66e9d22, F(-NAN) works just as
well as -F(NAN).
This avoids test issues with recent optimizations in LLVM.
https://github.com/llvm/llvm-project/pull/193586 seems to make
the compiler consider known symmetry for hyperbolic math functions,
exploiting the fact that cosh(-x) is equal to cosh(x) (for values
other than NANs). By hiding the negation inside the F() wrapper,
the compiler can't reason about is existence.
The DWARF debug info should work just as well.
Since 8c03f400a837dc9333e54ab371e7904aa2bec43c in llvm-project,
llvm-symbolizer prefers DWARF over PDB if there is a DWARF section
in the inspected executable. Thus, in order to use PDB, one would
have to strip out any remnants of DWARF debug info from the executable,
like in run-lldb-tests.sh (e.g. by -Wl,-s).
For the purposes of this test, simplifying the setup to use DWARF
works just as well.
When calling make_indirect_call with a parameter which is known,
Clang, since the 18.x release, can end up producing a specialized
version of the function which omits the cfguard check call (as the
target is known) and calls the known target directly.
The function is marked with a noinline attribute, to avoid
the compiler optimizing out the cfguard check call when the
target is known, but even with a noinline function, the compiler
apparently can make a separate specialized version of it.
To avoid the compiler doing such optimizations, reference the
target function via a global variable - the compiler can't assume
anything about the contents of them (they could be altered between
initialization and reading them later).
This fixes the cfguard invalid_icall test with Clang 18.x, when
compiled with optimizations enabled.
It is available on all architectures by default now. Keep the
HAVE_OPENMP conditional within the test makefile to allow custom
testing without having it available.
Since using the ssp routines from mingw-w64 instead of those from
GCC's libssp, these messages are included in the piped output of
the process, so we can check for the right messages.
Use the TOOLEXT variable in run-tests.sh in the same way as in the
Makefile. The Makefile sets this variable automatically if invoked
by mingw32-make, but if running run-tests.sh in WSL with native
Windows compilers, then we need to set TOOLEXT manually when calling
run-tests.sh.
Allow skipping the cfguard failure tests when run in such a
configuration, since Linux make in WSL can't easily run cmd.exe
like in MSYS2.
This part of the tests does pass on glibc on x86_64 and on MSVC,
but fails on macOS (for some functions) and on glibc on aarch64
(for one function).
This is a somewhat overly pedantic test, but is useful for checking
the NAN preservation behaviour when modifying implementations.
Also print the sign bit explicitly - not all printf implementations
distinguish between NAN and -NAN when printed.
When some of the parameters to standard C functions are known
constants, the compiler can optimize out the call to the actual
function.
When built with fortification enabled, the compiler previously
didn't actually end up calling the __<func>_chk functions in
most cases, as it could optimize out much of the calls. Now all
tested function calls should end up emitted as intended, making
this actually do functional testing of the __<func>_chk function
implementations.
The literal NAN in MSVC is a negative NAN, while it is a positive one
in other environments. (strtod("NAN", NULL) did return a positive NAN
though.) In most tests where we test that NANs are preserved, the exact
sign doesn't matter much as long as it matches, but for some tests, it
does matter. Change to using variables with known representation
in the tests where it matters.
Also add a LL suffix to make a tricky constant more correct.
In MSVC, the variable initialization
long long i = -2147483648;
actually sets the variable to the positive value 2147483648 (both
in MSVC 2019 and 2022).
The macros F() and L() etc were meant for providing constants for
the tests, without the compiler seeing them as constants, to
avoid optimizing out the entire functions that are to be tested.
However in practice, the compiler is also able to optimize out
e.g. a call to strtol("42", NULL, 0), so this didn't have the
intended effect.
Instead make the macros wrap through a no-op function, but which
is indirected via a global function pointer. The compiler can't
reason about global variables keeping their values (they could be
modified by e.g. a constructor in a different object file, before
running the main function). This avoids needing to pass all values
through strtod/strtol etc.
Change some constants like 123456789012345, which are seen by
the compiler as integer constants (which aren't exactly representable
in floating point form) into 123456789012345.0, which the compiler
won't complain about being inexact.
Martin Storsjö