mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-11-23 05:40:09 +00:00
314526557e
In D144319, Clang tried to land a change that would cause some functions that are not supposed to return nullptr to optimize better. As reported in https://reviews.llvm.org/D144319#4203982, libc++ started seeing failures in its CI shortly after this change was landed. As explained in D146379, the reason for these failures is that libc++'s throwing `operator new` can in fact return nullptr when compiled with exceptions disabled. However, this contradicts the Standard, which clearly says that the throwing version of `operator new(size_t)` should never return nullptr. This is actually a long standing issue. I've previously seen a case where LTO would optimize incorrectly based on the assumption that `operator new` doesn't return nullptr, an assumption that was violated in that case because libc++.dylib was compiled with -fno-exceptions. Unfortunately, fixing this is kind of tricky. The Standard has a few requirements for the allocation functions, some of which are impossible to satisfy under -fno-exceptions: 1. `operator new(size_t)` must never return nullptr 2. `operator new(size_t, nothrow_t)` must call the throwing version and return nullptr on failure to allocate 3. We can't throw exceptions when compiled with -fno-exceptions In the case where exceptions are enabled, things work nicely. `new(size_t)` throws and `new(size_t, nothrow_t)` uses a try-catch to return nullptr. However, when compiling the library with -fno-exceptions, we can't throw an exception from `new(size_t)`, and we can't catch anything from `new(size_t, nothrow_t)`. The only thing we can do from `new(size_t)` is actually abort the program, which does not make it possible for `new(size_t, nothrow_t)` to catch something and return nullptr. This patch makes the following changes: 1. When compiled with -fno-exceptions, the throwing version of `operator new` will now abort on failure instead of returning nullptr on failure. This resolves the issue that the compiler could mis-compile based on the assumption that nullptr is never returned. This constitutes an API and ABI breaking change for folks compiling the library with -fno-exceptions (which is not the general public, who merely uses libc++ headers but use a shared library that has already been compiled). This should mostly impact vendors and other folks who compile libc++.dylib themselves. 2. When the library is compiled with -fexceptions, the nothrow version of `operator new` has no change. When the library is compiled with -fno-exceptions, the nothrow version of `operator new` will now check whether the throwing version of `operator new` has been overridden. If it has not been overridden, then it will use an implementation equivalent to that of the throwing `operator new`, except it will return nullptr on failure to allocate (instead of terminating). However, if the throwing `operator new` has been overridden, it is now an error NOT to also override the nothrow `operator new`. Indeed, there is no way for us to implement a valid nothrow `operator new` without knowing the exact implementation of the throwing version. In summary, this change will impact people who fall into the following intersection of conditions: - They use the libc++ shared/static library built with `-fno-exceptions` - They do not override `operator new(..., std::nothrow_t)` - They override `operator new(...)` (the throwing version) - They use `operator new(..., std::nothrow_t)` We believe this represents a small number of people. Fixes #60129 rdar://103958777 Differential Revision: https://reviews.llvm.org/D150610 |
||
|---|---|---|
| .. | ||
| DesignDocs | ||
| Helpers | ||
| ReleaseNotes | ||
| Status | ||
| AddingNewCIJobs.rst | ||
| BuildingLibcxx.rst | ||
| CMakeLists.txt | ||
| conf.py | ||
| Contributing.rst | ||
| FeatureTestMacroTable.rst | ||
| Hardening.rst | ||
| ImplementationDefinedBehavior.rst | ||
| index.rst | ||
| Modules.rst | ||
| README.txt | ||
| ReleaseNotes.rst | ||
| ReleaseProcedure.rst | ||
| TestingLibcxx.rst | ||
| UsingLibcxx.rst | ||
libc++ Documentation ==================== The libc++ documentation is written using the Sphinx documentation generator. It is currently tested with Sphinx 1.1.3. To build the documents into html configure libc++ with the following cmake options: * -DLLVM_ENABLE_SPHINX=ON * -DLIBCXX_INCLUDE_DOCS=ON After configuring libc++ with these options the make rule `docs-libcxx-html` should be available. The documentation in this directory is published at https://libcxx.llvm.org. It is kept up-to-date by a build bot: https://lab.llvm.org/buildbot/#/builders/publish-sphinx-docs. If you notice that the documentation is not updating anymore, please contact one of the maintainers.