Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This changes behavior.
Currently libc++ only provides its own definitions of a math function if there's a macro which is normally used to define it.
Now libc++ always provides those overloads. That could cause redefinition errors.
I know there's been a lot of churn in this header recently , so maybe the diff I'm reading is out of date, but please verify that's the case.
Let's talk about signbit just to simplify things, but this applies to all of them AFAICT. My understanding is that C implementations are required to make this a macro: https://en.cppreference.com/w/c/numeric/math/signbit
If that were not the case, previously we would not have been defining signbit, so we would have been non-confirming because C's signbit only works with floating point, whereas C++'s signbit is supposed to work with integral types as well: https://en.cppreference.com/w/cpp/numeric/math/signbit
In other words, I'm not sure there are many C implementations that define them as functions, but I may be wrong. I know GCC and the macOS SDK both define them as macros.
In addition, if a library does not define e.g. isnan at all (neither as a macro nor as a function), our <math.h> will currently do the wrong thing because we won't define isnan at all. After this patch, we'll define it using the builtins, which is what we want to be doing. This makes the library easier to port to freestanding platforms.
(This applies to all the functions touched by this patch, of course)
This seems correct to me. I think it's not impossible that this will cause issues on some more obscure platforms that we don't know about and don't officially support, however I see no way of really figuring out what the issues would be without landing it and waiting to see whether it's actually causing problems. But from the CI and the few platforms we have downstream, this should not be a problem.
Adding libc++ vendors just for awareness.
Why isn't this below?