Commit Graph

368 Commits

Author SHA1 Message Date
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 72117f2ffe [runtimes] Properly handle the sysroot/triple/gcc-toolchain
In 395271a, I simplified how we handled the target triple for the
runtimes. However, in doing so, we stopped considering the default
in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE
(which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified.
This commit fixes that problem and also refactors the code so that it's
easy to see what the default value is.

The fact that nobody seems to have been broken by this makes me think
that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the
triple -- but it should still work.

Differential Revision: https://reviews.llvm.org/D111672
2021-10-21 10:06:11 -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
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 54a8a0d09a [runtimes] Allow FOO_TEST_CONFIG to be a relative path
That makes it possible to store that value in a CMake cache if needed.

Differential Revision: https://reviews.llvm.org/D110843
2021-10-05 19:45:50 -04:00
Mark de Wever f881776175 [libc++] Require a C++20 capable compiler.
This enforces libcxx and its benchmarks are compiled by a C++20 capable
compiler. Based on review comments in D103413.

Differential Revision: https://reviews.llvm.org/D110338
2021-09-24 11:38:26 -04:00
Louis Dionne cf765b1929 [libc++][NFC] Reindent documentation for LIBCXX_ENABLE_UNICODE 2021-09-09 11:14:39 -04:00
Martin Storsjö c4e8a2136c [runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs)
Differential Revision: https://reviews.llvm.org/D107892
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
Louis Dionne 3557c7c122 [libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs
Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.

Differential Revision: https://reviews.llvm.org/D108996
2021-09-01 10:51:09 -04:00
Louis Dionne 87dd51983c [libc++] Remove support for CloudABI, which has been abandoned
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of CloudABI specific
logic that had been added to support that platform.

Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT
coud be useful in their own right, however those are currently broken.
If we want to re-add such knobs in the future, we can do it like we've
done it for localization & friends so that we can officially support
that configuration.

Differential Revision: https://reviews.llvm.org/D108637
2021-08-24 14:11:32 -04:00
Tom Stellard 08c766a731 Bump the trunk major version to 14
and clear the release notes.
2021-07-27 21:58:25 -07: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
Louis Dionne 395271ad11 [runtimes] Simplify how we set the target triple
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.

This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.

Differential Revision: https://reviews.llvm.org/D106009
2021-07-16 10:33:39 -04:00
Louis Dionne a59165b017 [runtimes] Don't try passing --target flags to GCC
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.

This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.

One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.

Differential Revision: https://reviews.llvm.org/D106082
2021-07-15 16:52:02 -04:00
Louis Dionne 1f8e286cdc [libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst
As we automate more and more things in the library, it becomes useful for
contributors to have a single target for running all the automation as
part of their workflow. This commit adds a new `libcxx-generate-files`
target that should re-generate all the auto-generated files in the library.

As a fly-by, I also revamped the documentation on Contributing to account
for this new target and present it as a bullet list of things to check
before committing. I also added a few things that are often overlooked
to that list, such as updating the synopsis and the status files.

Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 12:07:26 -04:00
Louis Dionne 850b57c5fb [runtimes] Bring back TARGET_TRIPLE
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
2021-07-14 15:15:22 -04:00
Louis Dionne 5099e01568 [runtimes] Inherit the TARGET_TRIPLE that may be set by LLVM 2021-07-14 14:29:29 -04:00
Louis Dionne 77396bbc98 [runtimes] NFCI: Drop intermediate CMake variable TARGET_TRIPLE
We might as well use the various XXX_TARGET_TRIPLE variables directly.
2021-07-14 10:49:28 -04:00
John Ericson 1e03c37b97 Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.

This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.

One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.

Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).

---

Original message:

Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.

This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.

---

There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.

That last part should be the only behavior changes; everything else
should be a pure refactoring.

---

I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.

[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html

[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options

In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.

---

D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.

Reviewed By: phosek, #libc_abi, #libunwind

Differential Revision: https://reviews.llvm.org/D105765
2021-07-13 15:21:41 +00:00
Louis Dionne 6e43f3fc14 [libc++] Do not set CMAKE_BUILD_WITH_INSTALL_NAME_DIR
I'm not sure what that gains us, and it creates a problem when
trying to run the tests against libc++ with a custom install name
dir (e.g. /usr/lib), since the library that we link against (in
the build tree) will advertise itself as /usr/lib/libc++.dylib,
so we end up linking against the system dylib at runtime.

Differential Revision: https://reviews.llvm.org/D105499
2021-07-06 14:46:47 -04:00
Petr Hosek ea12d779bc [libc++] Support per-target __config_site in per-target runtime build
When using the per-target runtime build, it may be desirable to have
different __config_site headers for each target where all targets cannot
share a single configuration.

The layout used for libc++ headers after this change is:

```
include/
  c++/
    v1/
      <libc++ headers except for __config_site>
  <target1>/
    c++/
      v1/
        __config_site
  <target2>/
    c++/
      v1/
        __config_site
  <other targets>
```

This is the most optimal layout since it avoids duplication, the only
headers that's per-target is __config_site, all other headers are
shared across targets. This also means that we no need two
-isystem flags: one for the target-agnostic headers and one for
the target specific headers.

Differential Revision: https://reviews.llvm.org/D89013
2021-04-28 14:27:16 -07:00
Petr Hosek f749550cfe [libcxx] Stop using use c++ subdirectory for libc++ library
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.

Differential Revision: https://reviews.llvm.org/D100869
2021-04-21 15:39:03 -07:00
Petr Hosek 96d8c6b571 [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.

Differential Revision: https://reviews.llvm.org/D99697
2021-04-01 10:13:07 -07:00
Marek Kurdej 5c703f0fd8 [libc++] Build and test with -Wundef warning. NFC.
This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h".

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D99515
2021-04-01 08:32:56 +02:00
Louis Dionne c06a8f9caa [libc++] Include <__config_site> from <__config>
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.

This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.

It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.

Differential Revision: https://reviews.llvm.org/D97572
2021-03-30 14:06:11 -07:00
Martin Storsjö 1540646dbd [libcxx] Don't add -Wall when building in MSVC mode
The MSVC -Wall (or /Wall) option maps (in clang-cl) to the GCC style
option -Weverything, which we don't really want. Instead use -W4 which
is the corresponding MSVC option.

This silences the build with clang-cl, which previously used to
output 100 warnings per translation unit.

Differential Revision: https://reviews.llvm.org/D98035
2021-03-05 23:48:02 +02:00
Martin Storsjö 99fc4a6584 [libcxx] Enable filesystem by default for mingw targets
This feature can be built successfully for windows now. However,
the helper functions for __int128_t aren't available in MSVC
configurations, so don't enable it by default there yet. (See
https://reviews.llvm.org/D91139 for discussion on how to proceed
with things in MSVC environments.)

Differential Revision: https://reviews.llvm.org/D97075
2021-02-20 01:09:10 +02:00
Zbigniew Sarbinowski 5f9be2c3e3 [SystemZ][ZOS] Prefer -nostdlib++ as opposed to -nodefaultlibs when building c++ libraries
Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before.

This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out.

The propose change will allow to make the link step simple for other platforms as well.

Reviewed By: #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D95875
2021-02-16 18:42:14 +00:00
Tom Stellard 5369517d20 Bump the trunk major version to 13
and clear the release notes.
2021-01-26 19:37:55 -08:00
Marek Kurdej 5e7a93a954 [libc++] Set CMAKE_FOLDER. NFC.
* This variable populates the default value of FOLDER target property. It is used in some IDE's (e.g. MSVC) to group different targets together.
2021-01-25 09:51:16 +01:00
Louis Dionne 933518fff8 [libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.

This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.

Differential Revision: https://reviews.llvm.org/D94921
2021-01-19 14:15:48 -05:00
Raul Tambre 480643a95c [CMake] Remove dead code setting policies to NEW
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.

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

Differential Revision: https://reviews.llvm.org/D94374
2021-01-19 17:19:36 +02:00
Marek Kurdej 3b625060fc [libc++] [libc++abi] Use C++20 standard.
This change is needed to use char8_t when building libc++.
Using the same standard in libc++abi for coherence.

See https://reviews.llvm.org/D91517.

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D91691
2020-11-22 15:57:25 +01:00
Louis Dionne be00e8893f [libc++] Clarify how we pick the typeinfo comparison
This commit makes it clear that the typeinfo comparison implementation
is automatically selected by default, and that the CMake option only
overrides the value. This has been a source of confusion and bugs ever
since we've introduced complexity in that area, so I'm trying to simplify
it while still allowing for some control on the implementation.

Differential Revision: https://reviews.llvm.org/D91574
2020-11-18 16:58:45 -05:00
Louis Dionne 7ad8e19958 [libc++] Move the GDB pretty printer tests to the DSL
Also, enable them whenever we detect that gdb is available. Previously,
these tests would basically never run because they relied on a CMake
configuration option that defaulted to OFF.

Differential Revision: https://reviews.llvm.org/D91434
2020-11-16 16:16:39 -05:00
Zbigniew Sarbinowski aa8a5b800d [SystemZ][ZOS] libcxx - no posix memalign
The unavailability of posix_memalign on z/OS forces us to define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION'. The use of posix_memalign is being used in libcxx/src/new.cpp.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D90178
2020-11-12 14:47:58 -05:00
Louis Dionne 2eadbc8614 [libc++] Rework the whole availability markup implementation
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.

For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.

In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.

Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).

Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 12:28:52 -05:00
Louis Dionne 6706342f48 [libc++] Remove the ability to not install the support headers
Those are part of the library, and shipping them just adds a tiny bit of
size to the distribution. This was originally added in b422ecc7de to
make it possible to match the Makefile build, which doesn't exist anymore.

The upside is build system simplification.
2020-11-04 11:45:34 -05:00
Martin Storsjö 8a73aa8c4c [libcxx] [libcxxabi] Set flags for visibility when statically linking libcxxabi into libcxx for windows
Previously, these had to be set manually when building each of the
projects standalone, in order to get proper symbol visibility when
combining the two libraries.

Differential Revision: https://reviews.llvm.org/D90021
2020-11-03 17:13:48 +02:00
Louis Dionne 88ffc72717 [libc++] Add a libc++ configuration that does not support localization
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.

Differential Revision: https://reviews.llvm.org/D90072
2020-10-27 14:56:30 -04:00
Louis Dionne 48e4b0fd3a [runtimes] Revert the libc++ __config_site change
This is a massive revert of the following commits (from most revent to oldest):

	2b9b7b5775.
	529ac33197
	28270234f1
	69c2087283
	b5aa67446e
	5d796645d6

After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.

These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.

See https://reviews.llvm.org/D89041 for more details on this adventure.
2020-10-23 09:41:48 -04:00
Louis Dionne 69c2087283 [libc++] Fix compiler-rt build by copying libc++ headers to <build>/include
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.

I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
2020-10-21 16:56:33 -04:00
Louis Dionne 5d796645d6 [take 2] [libc++] Include <__config_site> from <__config>
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.

This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.

It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.

This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.

Differential Revision: https://reviews.llvm.org/D89041
2020-10-21 10:40:33 -04:00
Louis Dionne eb60c48744 [libc++] Revert "Include <__config_site> from <__config>"
This temporarily reverts commit 1e46d1aa until I find a solution to fix
the libc++abi and libunwind test suites with that change.
2020-10-21 09:18:29 -04:00
Louis Dionne 1e46d1aa3f [libc++] Include <__config_site> from <__config>
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.

This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.

It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.

Differential Revision: https://reviews.llvm.org/D89041
2020-10-21 08:46:57 -04:00
Louis Dionne 9b40ee8eb0 [libc++] Define new/delete in libc++abi only by default
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).

My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.

Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.

On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.

On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.

Differential Revision: https://reviews.llvm.org/D68269
2020-10-19 11:35:01 -04:00
Louis Dionne e0d01294bc [libc++] Allow building libc++ on platforms without a random device
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.

Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
2020-10-15 12:20:29 -04:00
Dominik Montada 8c03fdf34a [libcxxabi,libunwind] support running tests in standalone mode
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.

Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.

Reviewed By: ldionne, #libc_abi, #libc

Differential Revision: https://reviews.llvm.org/D86540
2020-10-14 09:10:20 +02:00
Raphael Isemann 6b7a49bb43 Fix all the CMake code that can only handle -stdlib= but not --stdlib=
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).

This just adds the alternative spelling before the`-stdlib=` variant in all
these places

Reviewed By: ldionne

Differential Revision: https://reviews.llvm.org/D87133
2020-10-13 16:05:21 +02:00