Proposal P0533R9 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.

The feature is enabled with a combination of the /std:c++23 or later and /Zc:cmath compiler options. It is initially shipping as experimental and off by default because our implementation is powered by a new math library at compile-time and runtime, 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.

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!

Today’s Situation

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 Introducing the Universal CRT for more information on this CRT restructuring.

In the modern day, the UCRT math functions have known mathematical inaccuracies. See Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision by 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.

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.

Why a New Math Library

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:

• Accuracy. Numerical results are as mathematically accurate as possible.
• Stability. Numerical results do not change over time due to implementation changes.
• Consistency. Numerical results do not change based on where they are executed.
• Performance. Numbers go brrr.

The UCRT failed to meet these lofty requirements, so we sought alternatives. We first entertained authoring a new library ourselves but quickly realized that would require years of monk-like study. We instead turned to the open-source community, focusing exclusively on solving the compile-time portion of C++23’s cmath feature (and thereby leaving the runtime execution to the UCRT) because we felt that delivering accuracy at runtime would still be computationally infeasible.

We found that the LLVM C Library had already made incredible progress tackling the math portions of the C runtime. The project upholds accuracy as the primary goal, aiming for correct rounding in all rounding modes, with Gladman, et al. confirming the project’s success. By targeting mathematical accuracy, the library effectively codifies a stable interface that allows for implementation flexibility and optimization. The library is actively maintained and has a healthy community supporting it.

Peeking into the code showed a cogent, composable codebase that could easily be adapted to build with MSVC. Once we did, we were pleasantly surprised that the performance numbers often rivaled those of the UCRT. This made shipping the library for use at compile-time and runtime viable. This enables us to offer our users consistent, stable, accurate, and performant mathematical results everywhere their programs run.

What’s Next

We believe that mathematical accuracy in floating-point libraries is an idea whose time has come. We are sure libc gives us the means to offer a stable ground for our users to build upon, but feedback is key for us in deciding how and when to roll the feature out. Please try the experimental implementation by adding /Zc:cmath to your build and reporting any issues you find to us on Visual Studio Developer Community. It is intended to be usable independently of /std:c++23 to enable the new runtime, though compile-time evaluation is only available in C++23. Support down-level has not yet shipped but has been merged internally. See microsoft/STL#6425 for more information.

Building and integrating LLVM libc into the toolset has been the lion’s share of this feature. Because we’ve done that work for C++23, C++26 can build upon that base without upheaval. LLVM libc has not yet implemented all of the functions that became constexpr in C++26, but we have already added support for the functions that are ready (such as sin, cos, tan, and pow). We’re keeping an eye on those that aren’t yet (such as lgamma).

We aimed to keep this post relatively short, but we have some upcoming blog posts discussing details of this feature. The first is a guest post authored by libc maintainers that digs into the incredible research and engineering that has gone into producing libc. The second is a post that explains some of the tricks we pulled in the C++ build tools to ship the feature.

Stay tuned!

Cody Miller

Microsoft C++ Compiler Frontend Engineer