{"id":36865,"date":"2026-09-10T21:19:59","date_gmt":"2026-09-10T21:19:59","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=36865"},"modified":"2026-09-10T21:19:59","modified_gmt":"2026-09-10T21:19:59","slug":"msvc-c23-constexpr-cmath-with-llvm-libc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/msvc-c23-constexpr-cmath-with-llvm-libc\/","title":{"rendered":"MSVC C++23: constexpr cmath with LLVM Libc"},"content":{"rendered":"

Proposal P0533R9<\/a> made numerous math functions in the standard library compile-time evaluable in C++23. Implementing the feature required a good bit of time and effort, but MSVC is preparing its experimental implementation for the 14.52 build tools (compiler version 19.52)! We are still refining the feature, so expect the dust to settle only when this has shipped for production.<\/p>\n

The feature is enabled with a combination of the \/std:c++23<\/code>\u00a0or later and\u00a0\/Zc:cmath<\/code>\u00a0compiler options. It is initially shipping as experimental and off by default because our implementation is powered by a new math library at compile-time\u00a0and<\/em>\u00a0runtime, which can change performance and accuracy characteristics for existing programs. Our aim is to collect user feedback before making decisions about default behaviors, so please try the feature and give us feedback on Visual Studio Developer Community<\/a>.<\/p>\n

We’re publishing an accompanying series of blog posts to explain why we opted for a new math library, what the new math library has to offer users, and an explanation of what we did to implement the feature in the compiler, starting with this post!<\/p>\n

Today’s Situation<\/h2>\n

Since 2015, the math functions in cmath and cstdlib are supplied by the C runtime via math.h and stdlib.h, which Microsoft ships as part of the Universal C Runtime (UCRT). The UCRT is maintained and deployed by the Windows operating system (OS) team, rather than the C++ tools team. This allows stable portions of the C runtime to be serviced in-place with OS updates, while portions tied to the toolset are shipped with the C++ build tools. Thanks to the immortal nature of the C++ Team Blog, you can travel back to 2015 and read\u00a0Introducing the Universal CRT<\/a>\u00a0for more information on this CRT restructuring.<\/p>\n

In the modern day, the UCRT math functions have known mathematical inaccuracies. See\u00a0Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision<\/a>\u00a0by Gladman, et al. for more info (it’s hot off the press). These inaccuracies stem from implementations that are quite old, dating to times when accuracy was often computationally infeasible. These implementations today are infrequently changed to maintain backwards compatibility, though they do receive occasional accuracy updates by the OS group.<\/p>\n

Inaccurate but changing math functions that are deployed by the OS result in mathematical computations that depend on the OS version and hardware architecture on which they are executed. OS upgrades or porting a program to another architecture (such as x64 to arm64) can quietly and surprisingly impact the results of some UCRT math functions.<\/p>\n

Why a New Math Library<\/h2>\n

This situation seemed untenable to us in C++23 because compile-time evaluation of math functions can become part of an application binary interface (ABI) in surprising ways, such as being supplied as an argument to a template. After much discussion, we narrowed on criteria that we found customers care about:<\/p>\n