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
--- 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
@@ -12,22 +12,13 @@
 
 // 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:
-// - 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.
+// In MSVC environments, some tested aspects are ifdeffed out, due to these issues:
 // - 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.
+//   tests of hex float formatting. (test7() and test8() are ifdeffed out.)
 //   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
-// XFAIL: msvc
 
+// XFAIL: broken-printf-g-precision
 // XFAIL: LIBCXX-AIX-FIXME
 
 #include <locale>
@@ -14308,6 +14299,7 @@
 
 void test7()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
@@ -16093,10 +16085,12 @@
             }
         }
     }
+#endif
 }
 
 void test8()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
@@ -17882,6 +17876,7 @@
             }
         }
     }
+#endif
 }
 
 int main(int, char**)
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
--- 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,22 +12,13 @@
 
 // iter_type put(iter_type s, ios_base& iob, char_type fill, long double v) const;
 
-// 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.
+// In MSVC environments, some tested aspects are ifdeffed out, due to these issues:
 // - 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.
+//   tests of hex float formatting. (test11() is ifdeffed out.)
 //   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
-// XFAIL: msvc
 
+// XFAIL: broken-printf-g-precision
 // XFAIL: LIBCXX-AIX-FIXME
 
 #include <locale>
@@ -22634,6 +22625,7 @@
 
 void test11()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
@@ -24419,6 +24411,7 @@
             }
         }
     }
+#endif
 }
 
 void test12()
@@ -24428,6 +24421,8 @@
 #if (defined(__APPLE__) || defined(TEST_HAS_GLIBC) || defined(__MINGW32__)) && defined(__x86_64__)
 // This test is failing on FreeBSD, possibly due to different representations
 // of the floating point numbers.
+// This test is failing in MSVC environments, where long double is equal to regular
+// double, and instead of "0x9.32c05a44p+27", this prints "0x1.26580b4880000p+30".
     const my_facet f(1);
     char str[200];
     {
diff --git a/libcxx/utils/libcxx/test/features.py b/libcxx/utils/libcxx/test/features.py
--- a/libcxx/utils/libcxx/test/features.py
+++ b/libcxx/utils/libcxx/test/features.py
@@ -85,6 +85,19 @@
           }
           """)),
 
+  # Check for a Windows UCRT bug (fixed in UCRT/Windows 10.0.19041.0).
+  # https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
+  Feature(name='broken-printf-g-precision',
+          when=lambda cfg: '_WIN32' in compilerMacros(cfg) and not programSucceeds(cfg, """
+          #include <stdio.h>
+          #include <string.h>
+          int main(int, char**) {
+            char buf[100];
+            snprintf(buf, sizeof(buf), "%#.*g", 0, 0.0);
+            return strcmp(buf, "0.");
+          }
+          """)),
+
   # Whether Bash can run on the executor.
   # This is not always the case, for example when running on embedded systems.
   #