MSVC Replaces Its Math Library With LLVM Libc for C++23 Constexpr Evaluation
When you call std::sin in a C++ program on Windows, the function comes from the Universal C Runtime. The UCRT is maintained by the Windows OS team, not the C++ tools team, and its math implementations date to an era when computational accuracy was often infeasible. A recent paper by Gladman and collaborators confirmed what many had suspected: the UCRT math functions have known mathematical inaccuracies. Worse, the implementations change infrequently to preserve backwards compatibility, but when they do change, or when you port your program from x64 to arm64, the results of some functions can quietly shift.
That is a problem for C++23. The standard now requires many cmath functions to be evaluable at compile time, per proposal P0533R9. Compile-time evaluation can become part of an application binary interface in surprising ways, such as being supplied as a template argument. If the compile-time result differs from the runtime result, or if the runtime result changes between OS versions, the behavior of a program can depend on when and where it was built and executed. The Microsoft C++ team decided this situation was untenable.
The LLVM Libc Choice
On September 10, 2026, Cody Miller, a Microsoft C++ Compiler Frontend Engineer, published a blog post explaining the solution: MSVC is replacing its math library with LLVM's C Library for both compile-time and runtime use. The feature is shipping as experimental in the 14.52 build tools (compiler version 19.52), enabled with the combination of /std:c++23 or later and the new /Zc:cmath compiler option.
The team evaluated four criteria that customers said they cared about. Accuracy: numerical results should be as mathematically correct as possible. Stability: results should not change over time due to implementation changes. Consistency: results should not change based on where the program runs. Performance: the new library should not be slower than the old one. The UCRT failed to meet these requirements, so the team looked for alternatives.
Authoring a new math library from scratch would have taken years. The team turned to the open-source LLVM C Library, which had already made significant progress on the math portions of the C runtime. The LLVM project upholds accuracy as its primary goal, aiming for correct rounding in all rounding modes. Gladman's paper confirmed the project's success on that front. The library is actively maintained and has a healthy community.
When the team adapted the LLVM libc codebase to build with MSVC, the performance numbers often rivaled those of the UCRT. That made shipping the library for both compile-time and runtime use viable. The result is consistent, stable, accurate, and performant mathematical results across platforms.
What the Compiler Option Actually Does
The /Zc:cmath flag switches MSVC from the UCRT math functions to LLVM libc. It can be used independently of /std:c++23, meaning you can enable the new runtime without enabling compile-time evaluation. Compile-time evaluation of math functions is only available when /std:c++23 or later is also specified.
The feature is experimental and off by default. Microsoft is collecting user feedback before making decisions about default behaviors. This is a deliberate choice: changing the math library for existing programs can affect performance and accuracy characteristics. Programs that depend on specific floating-point behavior might see different results with LLVM libc than they did with UCRT.
A comment on the blog post asked whether users will eventually be able to choose between different accuracy and performance trade-offs, such as correctly rounded results versus maximum performance. Miller responded that there are no concrete plans for that yet, but that user feedback will help gauge interest in exploring the space. The focus right now is on delivering this particular configuration.
The UCRT Problem
Since 2015, math functions in cmath and cstdlib have been supplied by the UCRT via math.h and stdlib.h. The UCRT is part of the Universal C Runtime, deployed by the Windows OS team. This separation made sense for stable portions of the C runtime that could be serviced in-place with OS updates, while toolset-dependent portions shipped with the C++ build tools.
The problem is that the UCRT math implementations are old, infrequently updated, and occasionally inaccurate. When they are updated, or when a program is ported to a different architecture, the results can change without warning. For a feature like constexpr cmath, where the compile-time result might become part of an ABI, this instability is a serious concern. A template instantiated at compile time with one result might link against runtime code that produces a different result.
C++26 Is Already in View
Building and integrating LLVM libc into the MSVC toolset has been the major engineering effort for this feature. Because the work is done, C++26 can build on that foundation without a major overhaul. LLVM libc has not yet implemented all the functions that became constexpr in C++26, but MSVC has already added support for the ones that are ready: sin, cos, tan, and pow. The team is watching functions that are not yet available, such as lgamma.
This is a significant head start. The constexpr cmath feature for C++23 required solving the hard problem of building and shipping LLVM libc inside the MSVC toolset. Now that the infrastructure exists, adding constexpr support for additional functions in future standards is a matter of implementation, not architecture.
Practical Impact for Developers
For developers working on code that needs compile-time math evaluation, the feature enables patterns that were previously impossible in MSVC. You can compute mathematical constants, generate lookup tables, and validate numerical algorithms at compile time with the same results you will get at runtime. The consistency guarantee means the compile-time result and the runtime result will match, regardless of OS version or hardware architecture.
For developers not using C++23 constexpr features, the /Zc:cmath flag still changes the runtime math library. The LLVM libc implementations may produce slightly different results than UCRT for edge cases, which is the point. The accuracy improvements come at the cost of potential behavioral changes for existing programs. Testing is recommended before enabling the flag on production code.
The experimental designation means the feature is not final. Microsoft is asking developers to try it and report issues through Visual Studio Developer Community. The feedback will determine when and how the feature transitions from experimental to production, and whether it eventually becomes the default behavior.