This is an archive of the discontinued LLVM Phabricator instance.

[libc++][math.h] move #undefs to the top and guard explicitly against MSVCRT instead
ClosedPublic

Authored by philnik on Nov 5 2022, 1:58 PM.

Diff Detail

Event Timeline

philnik created this revision.Nov 5 2022, 1:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 5 2022, 1:58 PM
philnik requested review of this revision.Nov 5 2022, 1:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 5 2022, 1:58 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne accepted this revision.Nov 21 2022, 8:30 AM

LGTM pending CI too.

All in all, this whole stack is pretty much a NFC refactoring, but it makes things a lot nicer. Thanks!

libcxx/include/math.h
306–308

Why isn't this below?

368

Here and for all the other ones. We don't gain anything from these comments anymore, they just clutter the code.

This revision is now accepted and ready to land.Nov 21 2022, 8:30 AM
EricWF requested changes to this revision.Nov 21 2022, 9:42 AM
EricWF added a subscriber: EricWF.

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.

This revision now requires changes to proceed.Nov 21 2022, 9:42 AM

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.

ldionne added a comment.EditedNov 23 2022, 7:57 AM

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)

philnik updated this revision to Diff 477647.Nov 23 2022, 4:23 PM
philnik marked 2 inline comments as done.
  • Rebased
  • Address comments
ldionne accepted this revision.Nov 24 2022, 9:00 AM
ldionne added a subscriber: Restricted Project.

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.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 29 2022, 3:50 PM
This revision was automatically updated to reflect the committed changes.