[libcxx-commits] [libcxx] 77c7ce0 - [libcxx] [test] Make the put_long_double test pass on mingw, clarify quirks in put_double

[Martin Storsjö via libcxx-commits]

Author: Martin Storsjö
Date: 2022-02-17T10:53:28+02:00
New Revision: 77c7ce03845d31b1c92cc2a93d56f2efa485964f

URL: https://github.com/llvm/llvm-project/commit/77c7ce03845d31b1c92cc2a93d56f2efa485964f
DIFF: https://github.com/llvm/llvm-project/commit/77c7ce03845d31b1c92cc2a93d56f2efa485964f.diff

LOG: [libcxx] [test] Make the put_long_double test pass on mingw, clarify quirks in put_double

Expect the same NAN formatting on Windows as on Glibc. (Both MSVC and
MinGW produce the same formatting there.)

The hex float formatting tests pass on MinGW, so opt in to those tests.

Document exactly what issues are remaining in Clang-cl/MSVC
configurations. (It's easily possible to make the tests pass there too,
but it requires a whole lot of small-scope ifndefs in the test file;
around 60 ifdefs in total for those both test files. Those could
be avoided if the CI environment could run with a newer version
of UCRT, but that's nontrivial to fix right away.)

Differential Revision: https://reviews.llvm.org/D119766

Added: 
    

Modified: 
    libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp
    libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp

Removed: 
    


################################################################################
diff  --git a/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp b/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp
index 6554e603d3646..08c9718e68e72 100644
--- a/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp
+++ b/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp
@@ -13,7 +13,19 @@
 // iter_type put(iter_type s, ios_base& iob, char_type fill, double v) const;
 
 // FIXME: The printf functions in Microsoft's CRT have a couple quirks in
-// corner cases, failing this test.
+// corner cases, failing this test:
+// - With the Microsoft UCRT, printf("%#.*g", 0, 0.0) produces "0.0" while
+//   other C runtimes produce "0.". For other precisions than 0, Microsoft's
+//   consistently produce one digit more than others. In the MinGW test setups,
+//   the code is built with __USE_MINGW_ANSI_STDIO=1, which uses MinGW's own
+//   reimplementation of stdio functions, which doesn't have this issue.
+//   This bug requires excluding everything that runs with showpoint() enabled.
+//   https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
+//   This issue is fixed in newer UCRT versions, since 10.0.19041.0.
+// - With the Microsoft UCRT, printf("%a", 0.0) produces "0x0.0000000000000p+0"
+//   while other C runtimes produce just "0x0p+0". This requires omitting all
+//   tests of hex float formatting.
+//   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
 // XFAIL: msvc
 
 // XFAIL: LIBCXX-AIX-FIXME

diff  --git a/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp b/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
index a41efe746db62..2eebc1cabc958 100644
--- a/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
+++ b/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
@@ -12,7 +12,22 @@
 
 // iter_type put(iter_type s, ios_base& iob, char_type fill, long double v) const;
 
-// XFAIL: LIBCXX-WINDOWS-FIXME
+// FIXME: The printf functions in Microsoft's CRT have a couple quirks in
+// corner cases, failing this test:
+// - With the Microsoft UCRT, printf("%#.*g", 0, 0.0) produces "0.0" while
+//   other C runtimes produce "0.". For other precisions than 0, Microsoft's
+//   consistently produce one digit more than others. In the MinGW test setups,
+//   the code is built with __USE_MINGW_ANSI_STDIO=1, which uses MinGW's own
+//   reimplementation of stdio functions, which doesn't have this issue.
+//   This bug requires excluding everything that runs with showpoint() enabled.
+//   https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
+//   This issue is fixed in newer UCRT versions, since 10.0.19041.0.
+// - With the Microsoft UCRT, printf("%a", 0.0) produces "0x0.0000000000000p+0"
+//   while other C runtimes produce just "0x0p+0". This requires omitting all
+//   tests of hex float formatting.
+//   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
+// XFAIL: msvc
+
 // XFAIL: LIBCXX-AIX-FIXME
 
 #include <locale>
@@ -10717,7 +10732,7 @@ void test5()
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
     const my_facet f(1);
-#if defined(TEST_HAS_GLIBC)
+#if defined(TEST_HAS_GLIBC) || defined(_WIN32)
     std::string pnan_sign = "+";
     std::string pnan_padding25 = "*********************";
 #else
@@ -24410,7 +24425,7 @@ void test12()
 {
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
-#if (defined(__APPLE__) || defined(TEST_HAS_GLIBC)) && defined(__x86_64__)
+#if (defined(__APPLE__) || defined(TEST_HAS_GLIBC) || defined(__MINGW32__)) && defined(__x86_64__)
 // This test is failing on FreeBSD, possibly due to 
diff erent representations
 // of the floating point numbers.
     const my_facet f(1);