[libcxx-commits] [libcxx] WIP [libc++][math] Add `constexpr` to `copysign`, `copysignf`, `copysignl` (PR #216285)

[Richard Smith via libcxx-commits]

zygoloid wrote:

> And yet it's one GCC supports: https://godbolt.org/z/qvTdfTbGj, https://godbolt.org/z/6hdWhx1rc unless you have something different in mind?

Yeah. We could possibly follow that in `GNUMode`, but that's still going to be problematic in other ways (see below).

> Is there a third option of relaxing the standard requirement (as a DR) that implementations cannot add `constexpr` to library functions?

The committee already said no to that ([LWG2013](https://cplusplus.github.io/LWG/issue2013)).

If we do add this in a non-conforming mode, I think we should require consistent behavior for (eg) `sin(1.0)` and `sin(1.0f)` -- a backport that only works for `sin(double)` but not `sin(float)` and maybe not for `std::sin(double)` seems worse to me than no backport. And that means that either we allow the standard library to choose which functions are `constexpr` (for example, we leave them non-constexpr and allow the standard library to provide constexpr declarations), or we decide and ignore the standard library (for both the libc functions we already handle and also all the C++ standard library overloads that we do not), or that we somehow arrange for the compiler and the standard library to agree (which probably means strictly following the standard).

It would definitely be possible to apply the "std:: builtin" treatment to all of these math functions and override the `constexpr`ness of them, ignoring what the standard library provides and also ignoring the standard library definitions. Then we could consistently DR this change, and put it behind a `-f` flag or GNU mode. But short of that, strictly following the standard seems like the way to get consistent behavior.

https://github.com/llvm/llvm-project/pull/216285