Commit Graph

252 Commits

Author SHA1 Message Date
Martin Storsjö dba90d74be [libcxx] Stop recommending setting LIBCXX_HAS_WIN32_THREAD_API in the MinGW builds
Since a8d15a9266 / D110975, this is
the default, even if winpthread headers are available, so we don't
need to cargo cult setting this option in all builds.

Differential Revision: https://reviews.llvm.org/D122717
2022-04-04 23:07:40 +03:00
Louis Dionne 65b1b3b961 [libc++][libc++abi] Serialize the enable_assertions Lit parameter in the generated config
This means that re-running with llvm-lit in that configuration will
work as expected. This also enables assertions in libc++abi in the
Generic-assertions CI job, which was disabled previously.

Differential Revision: https://reviews.llvm.org/D122597
2022-03-29 08:17:25 -04:00
Louis Dionne b0fd9497af [libc++] Add a lightweight overridable assertion handler
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.

This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).

This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.

As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:

- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
  in their code will still get basic assertions out of the box, but
  those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
  and friends will work out-of-the-box, no changes required. This is
  because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
  compiling, because we don't provide that declaration anymore. Users
  will have to migrate to the new way of setting a custom assertion
  handler, which is extremely easy. I suspect that pool of users is
  very limited, so breaking them at compile-time is probably acceptable.

The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.

Differential Revision: https://reviews.llvm.org/D121478
2022-03-23 15:35:46 -04:00
Louis Dionne 0389462587 [libc++] Do not install the C++ ABI library's headers as part of libc++'s build
It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.

Differential Revision: https://reviews.llvm.org/D121706
2022-03-16 08:53:47 -04:00
Michał Górny ba4f1e44e4 [libcxx] Add an explicit option to build against system-libcxxabi
Add an explicit LIBCXX_CXX_ABI=system-libcxxabi option for linking to
system-installed libc++abi. This fixes the ability to link against one
when building libcxx via the runtimes build, as otherwise the build
system insists on linking into in-tree targets.

Differential Revision: https://reviews.llvm.org/D119539
2022-03-01 13:44:56 -05:00
Louis Dionne 368faacac7 [libc++] Revert "Protect users from relying on detail headers" & related changes
This commit reverts 5aaefa51 (and also partly 7f285f48e7 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.

Differential Revision: https://reviews.llvm.org/D120683
2022-03-01 08:20:24 -05:00
Christopher Di Bella 5aaefa510e [libcxx][modules] protects users from relying on detail headers
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.

Differential Revision: https://reviews.llvm.org/D106124
2022-02-26 09:00:25 +00:00
David Spickett 9c720250d1 [libcxx][ci] Switch to CMAKE_CXX_COMPILER_TARGET for Arm bots
As suggested by the cmake warning:
CMake Warning at <...>/llvm-project/libcxx-ci/libcxx/CMakeLists.txt:289 (message):
  LIBCXX_TARGET_TRIPLE is deprecated, please use CMAKE_CXX_COMPILER_TARGET instead

Depends on D119948

Differential Revision: https://reviews.llvm.org/D120038
2022-02-22 09:42:55 +00:00
David Spickett 912bba5ae2 [libcxx][CI] Set Arm triples to match native clang build's default
We were using:
armv8-linux-gnueabihf
But for a native clang build the default target is:
armv8l-linux-gnueabihf

(ditto for v7)

Add the "l" to the target triples and update the one test
that is unsupported to look for the various possible names.

armv(7 or 8)(m or l, optionally)

The UNSUPPORTED does not include aarch64 because aarch64 Linux
(and others that follow Arm's AAPCS64) use quad precision for
long double where arm64 (darwin) does not:
https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#811arithmetic-types

Reviewed By: rovka

Differential Revision: https://reviews.llvm.org/D119948
2022-02-22 09:39:20 +00:00
Louis Dionne 1b06d2cf15 [libc++] Refactor the Apple build scripts
This patch upstreams some changes we've made internally to how we're
building the libc++ dylib on Apple platforms. The goal is still to
eventually get rid of `apple-install-libcxx.sh` entirely and have a
proper way to mirror what we do internally with just the normal CMake
configuration.

Differential Revision: https://reviews.llvm.org/D118912
2022-02-16 16:28:13 -05:00
Konstantin Varlamov 10953974ed [libc++][NFC] Work around false positive ODR violations from ASan.
This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.

The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.

Differential Revision: https://reviews.llvm.org/D119410
2022-02-11 11:56:51 -08:00
Nikolas Klauser 5488021f3e [libc++] Add Unstable ABI CI run
Reviewed By: ldionne, #libc, Mordante

Spies: mgorny, Mordante, libcxx-commits, arichardson

Differential Revision: https://reviews.llvm.org/D118725
2022-02-05 15:37:22 +01:00
Louis Dionne 99ae458231 [libc++] Add CI without experimental features and don't exclude span from the tests
There is no reason for the parts of std::span that don't depend on ranges
to be disabled when ranges aren't provided. Also, to make sure the
"no-experimental-stuff" configuration is tested, add a CI job for it.

Differential Revision: https://reviews.llvm.org/D118740
2022-02-02 10:48:35 -05:00
John Ericson 7017e6c9cf [cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm
We previously had a few varied definitions of this floating around.

I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.

 My compromise solution is this:

 - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.

- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.

- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.

In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.

The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.

Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D117537
2022-01-29 06:07:24 +00:00
Petr Hosek 10e5c513b5 Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm"
This reverts commit 4af11272f5.
2022-01-21 09:53:14 -08:00
John Ericson 4af11272f5 [cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.

This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.

Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D117537
2022-01-20 21:18:42 +00:00
John Ericson 429a717ea5 [cmake] Move HandleOutOfTreeLLVM to common cmake utils
This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.

It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.

Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314

Differential Revision: https://reviews.llvm.org/D117617
2022-01-19 22:05:23 +00:00
John Ericson f16a4a034a [libcxx][libcxxabi][libunwind][cmake] Use `GNUInstallDirs` to support custom installation dirs
I am breaking apart D99484 so the cause of build failures is easier to
understand.

Differential Revision: https://reviews.llvm.org/D117417
2022-01-18 06:44:57 +00:00
John Ericson da77db58d7 Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have
this odd error, not sure how to reproduce, so I will just try breaking
up my patch.

This reverts commit 4a678f8072.
2022-01-16 05:48:30 +00:00
John Ericson 4a678f8072 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484
2022-01-16 05:33:07 +00:00
John Ericson 6e52bfe09d Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
Sorry for the disruption, I will try again later.

This reverts commit efeb501970.
2022-01-15 07:35:02 +00:00
John Ericson efeb501970 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484
2022-01-15 01:08:35 +00:00
Ben Wagner fb1582f6c5 [libc++] Disable coverage with sanitize-coverage=0
When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.

The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.

CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).

The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.

Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek

Differential Revision: https://reviews.llvm.org/D116050
2022-01-07 17:53:21 -08:00
Nico Weber 085f078307 Revert "Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`.""
This reverts commit 859ebca744.
The change contained many unrelated changes and e.g. restored
unit test failes for the old lld port.
2022-01-05 13:10:25 -05:00
David Salinas 859ebca744 Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`."
This reverts commit 640beb38e7.

That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup

Change-Id: Ibf8e397df94001f248fba609f072088a46abae08

Reviewed By: kzhuravl

Differential Revision: https://reviews.llvm.org/D115960

Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
2022-01-05 17:57:32 +00:00
Martin Storsjö f68e89044a [libcxx] Add LIBCXX_EXTRA_SITE_DEFINES for adding extra defines in __config_site
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.

This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.

Differential Revision: https://reviews.llvm.org/D116109
2021-12-22 00:43:29 +02:00
Martin Storsjö 529a79302b Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Since the previous attempt, this no longer uses
llvm_enable_language_nolink (and thus doesn't set
CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler
sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
during compiler sanity checks makes cmake not learn about some
aspects of the compiler, which can make further find_library or
find_package fail. This caused OpenMP to not detect libelf and libffi,
disabling some OpenMP target plugins.

Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES
when building in a configuration with an incomplete toolchain.

Differential Revision: https://reviews.llvm.org/D113253
2021-12-09 21:38:14 +02:00
Martin Storsjö 62cff45d76 Revert "Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind"
This reverts commit 317dc31e53.

After that change, OpenMP doesn't find dependencies in the host
system (it fails do find e.g. /usr/lib/x86_64-linux-gnu/libelf.so
which it found before), which causes some OpenMP target offloading
plugins to not be found. This doesn't break the build, but just
causes the AMDGPU OpenMP target plugin to be omitted. See
https://reviews.llvm.org/D113253#3181934 for the report of this
issue.
2021-12-09 12:56:57 +02:00
Martin Storsjö 317dc31e53 Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Reapplying this after
db32c4f456, which should fix the issues
that were reported last time this was applied.

Differential Revision: https://reviews.llvm.org/D113253
2021-12-08 00:32:40 +02:00
Louis Dionne fa1c077b41 [runtimes] Remove support for GCC-style 32 bit multilib builds
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.

As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.

Differential Revision: https://reviews.llvm.org/D114473
2021-12-01 12:57:01 -05:00
Martin Storsjö efbe9ae23f Revert "[runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind"
This reverts commit 7c3d19ab7b.

This commit was reported as causing build problems for the amdgpu
buildbot in https://reviews.llvm.org/D113253#3137097.
2021-11-17 12:50:33 +02:00
Martin Storsjö f5ca3ac748 [libcxx] [ci] Add CI configurations for MinGW
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.

Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).

Differential Revision: https://reviews.llvm.org/D112215
2021-11-17 10:00:50 +02:00
Martin Storsjö 7c3d19ab7b [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Differential Revision: https://reviews.llvm.org/D113253
2021-11-16 23:04:06 +02:00
Petr Hosek 22acda48ff [CMake] Cache the compiler-rt library search results
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.

This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.

Differential Revision: https://reviews.llvm.org/D88458
2021-10-27 17:53:03 -07:00
Petr Hosek ba4920e98e Revert "[CMake] Cache the compiler-rt library search results"
This reverts commit 0eed292fba, there
are compiler-rt build failures that appear to have been introduced
by this change.
2021-10-21 10:32:01 -07:00
Louis Dionne cbe3b6b21f [libc++] Move LIBCXX-DEBUG-FIXME to params.py
This temporary FIXME really belongs to the testing config, not to the
specific CMake cache that enables that configuration.

Differential Revision: https://reviews.llvm.org/D112031
2021-10-20 09:23:03 -04:00
Petr Hosek 0eed292fba [CMake] Cache the compiler-rt library search results
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.

This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.

Differential Revision: https://reviews.llvm.org/D88458
2021-10-18 14:44:07 -07:00
Mikhail Dvorskiy 6069a6a504 [pstl] Initial implementation of OpenMP backend, on behalf of Christopher Nelson nadiasvertex@gmail.com
Phabricator Review:
https://reviews.llvm.org/D99836

A couple of parallel patterns still remains serial - "Parallel partial sort", and "Parallel transform scan" - there are //TODOs in the code.
2021-10-15 15:36:07 +03:00
David Tenty 228b3b729d [libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure
This initial change adds the AIX configuration to run-buildbot, an AIX
CMake cache file, and appropriate compiler and linker flags for testing
AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations
can be built by setting `OBJECT_MODE` in the build environment (as is
typical for AIX).

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D111244
2021-10-14 14:31:10 -04:00
Louis Dionne f4c1258d56 [libc++] Add an option to disable wide character support in libc++
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265
2021-10-12 06:08:23 -04:00
Louis Dionne f6a74908a7 [runtimes] Add tests for vendor-specific properties
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.

Differential Revision: https://reviews.llvm.org/D110736
2021-10-07 15:46:20 -04:00
Haowei Wu 138dc27186 Revert "[libc++][libc++abi] Add tests for vendor-specific properties"
This reverts commit 9892d1644f, which
causes clang test failures in libcxx tests.
2021-09-30 11:03:59 -07:00
Louis Dionne 9892d1644f [libc++][libc++abi] Add tests for vendor-specific properties
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

Differential Revision: https://reviews.llvm.org/D110736
2021-09-29 17:22:37 -04:00
Alfonso Gregory a2c319fdc6 [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D107717
2021-09-16 18:29:57 +02:00
Nehal J Wani 1613ab8a4a [libcxx][libcxxabi] CMAKE_REQUIRED_FLAGS is a string, not a list
When `libcxx` or `libcxxabi` is built with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`
**and** `-DLIBCXX[ABI]_USE_COMPILER_RT=ON`, all of the `LIBCXX[ABI]_SUPPORTS_*_FLAG`
checks fail, since the value of `CMAKE_REQUIRED_FLAGS` is not set correctly.

Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=51774

Reviewed By: #libc, #libc_abi, compnerd, ldionne

Differential Revision: https://reviews.llvm.org/D109342
2021-09-16 18:26:29 +02:00
Martin Storsjö a3870e8ab1 Reapply [runtimes] Set more paths when building runtimes standalone
These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

Fixed since previous attempt: Don't check if the runtimes directory
is the root of the CMake invocation; when the main LLVM CMake
build builds runtimes, it does invoke a sub-CMake with this directory
as the root too, just as if manually invoking CMake at the runtimes
directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and
whether find_package(LLVM) succeeded or not.

Differential Revision: https://reviews.llvm.org/D107895
2021-09-09 15:30:42 +03:00
Leonard Chan d96e0c5388 Revert "[runtimes] Set more paths when building runtimes standalone"
This reverts commit 407e07aa67.

Reverting since this seems to break OpenMP builds and our clang
builders. See thread on https://reviews.llvm.org/D107895.
2021-09-08 18:31:10 -07:00
Martin Storsjö 407e07aa67 [runtimes] Set more paths when building runtimes standalone
These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

Differential Revision: https://reviews.llvm.org/D107895
2021-09-09 00:01:38 +03:00
Mark de Wever df2af9936c [libc++][format] Add a CMake Unicode option.
This option is used to select between the format headers output column
width option. This option should be independent of the locale setting.
It's encouraged to default to Unicode unless the platform doesn't offer
that option.

[format.string.std]/10
```
  For the purposes of width computation, a string is assumed to be in a
  locale-independent, implementation-defined encoding. Implementations
  should use a Unicode encoding on platforms capable of displaying Unicode
```

Reviewed By: #libc, ldionne, vitaut

Differential Revision: https://reviews.llvm.org/D103379
2021-09-04 11:55:10 +02:00
Mark de Wever 71909de374 [libc++] Disable incomplete library features.
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.

The option is enabled by default.

Differential Revision: https://reviews.llvm.org/D106763
2021-07-27 22:37:35 +02:00