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

[Aaron Ballman via libcxx-commits]

AaronBallman 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)).

They did, but now there's two implementations looking to ignore that, so the question was more whether we think that's worth reopening the discussion over.

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

I was imagining the backport would behave the same for all of those cases (except perhaps `std::sin` because I'm still hoping we avoid trying to recognize namespaced library functions to the greatest extent we can). Basically, the FE would recognize "this is a (builtin) library call" and let the constexpr engine handle determining whether the call can be evaluated in a constant expression context given the arguments, rounding mode, compiler options, etc. So we'd be recognizing `sin`, `sinf`, and `sinl` (and eventually `sind32`, `sind64`, and `sind128`) in both language modes; `sin` in C is always `double sin(double)` and in C++ would be an overload set. Or do you think that's not workable?

> 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