We do provide operator delete(void*) in <new> but it should be
available by default. This is mostly boilerplate to test it and the
unconditional include of <new> in the header we always in include
on the device.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Headers/openmp_wrappers/__clang_openmp_device_functions.h | ||
---|---|---|
20 | I think there are legitimate use cases for writing code that doesn't include new. Can we add the forms that are meant to be available without the include here, instead of just pulling in all new? | |
clang/test/Headers/Inputs/include/cstdlib | ||
5 ↗ | (On Diff #337987) | These are in stdlib just above, no? Possibly with noexcept tags |
clang/lib/Headers/openmp_wrappers/__clang_openmp_device_functions.h | ||
---|---|---|
20 | Hm, what forms would you not like to see in the code by default, and why? | |
clang/test/Headers/Inputs/include/cstdlib | ||
5 ↗ | (On Diff #337987) | They are not, this is the sham layer for testing, but you are so far correct that they should be. I'll move them. |
clang/lib/Headers/openmp_wrappers/__clang_openmp_device_functions.h | ||
---|---|---|
20 | I would prefer the default includes exactly the expressions/syntax that C++ provides by default, which may mean writing some inline here though I'm perplexed that we need to do something different to clang compiling c++. I'd have to look up which operators are magic and which are in the header. At least some reluctance is that we don't have a gpu <new>, so this will be whatever host libstdc++/libc++ is in use, and I'd like to avoid including gpu-unaware code on the gpu wherever possible. |
cstdlib may not exist, probably in the same situations as new not existing, but that can probably be left until the problem arises. I think this looks reasonable, and it'll unblock some applications that don't presently build.
clang/lib/Headers/openmp_wrappers/__clang_openmp_device_functions.h | ||
---|---|---|
74 | free(nullptr) is well formed, don't think we need the branch here |
We might want a test that includes <new> along with this header, to check they don't conflict with one another
For that I need to replicate the potentially conflicting <new> stuff in the test header mockups. I'll try it later on one system though.
Yep, may not be able to check in something that pulls <new> out of the host system.
It seems inconvenient that clang doesn't automatically inject the new/delete forms that are intended to be available without including new.
Split the new/delete operators based on std::nothrow_t and provide the ones
that do not use this type by default, the others as part of <new>.
I think there are legitimate use cases for writing code that doesn't include new. Can we add the forms that are meant to be available without the include here, instead of just pulling in all new?