Make C-lib math functions introspection more robust

[am11]

On Solaris-like operating systems (such as SmartOS 2020 and OpenIndiana hipster), when built without optimization enabled (e.g. -O2); if the hard-coded value of -0.0 is used for x argument of atan2(3), it produces value of PI correctly, when y is 0.0.

However, it produces an incorrect result if the value of x is soft-coded and a unary operator is used, like -x.

The following program demonstrates the issue:

gcc -xc - -lm <<EOF
#include <stdio.h>
#include<math.h>
int main() {
  double x = 0.0;
  printf("hard-coded %g vs. soft-coded %g\n",
    atan2(0.0, -0.0),
    atan2(0.0, -x));
  return 0;
}
EOF

./a.out

gives us: hard-coded 3.14159 vs. soft-coded 0, with -O2, it produces the correct value (of PI for both hard- and soft- coded cases).

With clang-9 on OI, it gives us: hard-coded 0 vs. soft-coded 0 with and without -O2.

This is most likely the bug in libm, which I have reported in upstream channel.

We already have a fallback implementation under HAVE_COMPATIBLE_ATAN2.
This PR makes the test case more robust, so it fails on Solaris.

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[am11]

cc @jkotas, @janvorli

@janvorli, I have also fixed two CMake endif mismatch warnings with this PR, which was caused by my previous PR. e.g.

CMake Warning (dev) in src/pal/tests/palsuite/exception_handling/pal_sxs/test1/CMakeLists.txt:
  A logical block opening on the line
    /usbkey/home/root/runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/CMakeLists.txt:25 (if)
  closes on the line
    /usbkey/home/root/runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/CMakeLists.txt:27 (endif)
  with mis-matching arguments.

[danmoseley]

@maryamariyan bad label :)

[maryamariyan]

@danmosemsft I updated the bot labeler earlier today to undo applying labels based on the second fallback model.
for this specific PR however, we dont get to the fallback model at all since the confidence score is 0.92 (pretty high already using the main model).

[tannergooding]

Which tests caught this? We should have coverage of all the IEEE required inputs/outputs on both the managed and native side. For example:

• https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Extensions/tests/System/Math.cs#L582
• https://github.com/dotnet/runtime/blob/master/src/coreclr/src/pal/tests/palsuite/c_runtime/atan2/test1/test1.cpp

[danmoseley]

@maryamariyan oh ok. It's actually pretty reasonable from a bot POV.

[am11]

@tannergooding, currently:

• palsuite is not running in the CI for quite sometime (I think it has been one year, since the Jenkins to AzDO transition): Run PAL tests in CI #34776.

• PAL tests are not building on anything other than Linux, PR Fix PAL test build on non-Linux Unix platforms #35218 to address it.

• Which tests caught this?

  Yes, it was src/coreclr/src/pal/tests/palsuite/c_runtime/atan2/test1/test1.cpp.

[am11]

From cppreference - atan2:

If y is ±0 and x is negative or -0, ±π is returned

this case is violating on Illumos, which palsuite exercises. The incorrect result is produced, when compilers (clang, or gcc) do not make use of use of the builtin atan2, and instead calls the libm function which has this bug. Only gcc with -O2 uses the builtin function. We can force the compiler to skip builtin in all cases with -fno-builtin, then both clang and gcc, with and without -O2 produce 0 (instead of π) for hard- and soft- coded cases.

[janvorli]

LGTM, thank you!

[tannergooding]

This (and others checking against a "close enough" result) should ideally get cleaned up as well. IEEE floating-point is deterministic, if nothing else, and so the result should be exactly Math.PI (which is the nearest representation of "true pi").
I'll log a bug and see about following up after this gets merged.

[tannergooding]

Logged #35341