When doing standalone build, check that we actually have libcxxabi
before attempting to use it.
Differential Revision: https://reviews.llvm.org/D28580
llvm-svn: 291723
There is no guaranteed order in which CMake files for individual
runtimes are invoked and therefore we cannot rely on existence of
targets defined in other runtimes. Use the new HAVE_<name> options
instead in those cases.
Differential Revision: https://reviews.llvm.org/D28391
llvm-svn: 291632
This is to make sure this check is called even when building as
part of LLVM runtimes when we are doing standalone but not out of
tree build.
Differential Revision: https://reviews.llvm.org/D28392
llvm-svn: 291592
Need to allow unresolved symbols in the dylib. This was previously done for
LIBCXX_HAS_EXTERNAL_THREAD_API, but we have since split that into two with
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY being the externally-threaded variant.
Also a minor CMakeLists.txt cleanup.
llvm-svn: 291433
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
Move the windows specific macro definitions for compiling c++ into the
target. Add a number of newer options that are necessary to properly
build libc++ for windows. This ensures that we do not accidentally
autolink msvcprt (Microsoft's C++ runtime library), do not define linker
pragmas which are msvcprt specific, and do not accidentally encode the
incorrect version of the msvc compatibility version.
llvm-svn: 290837
This allows us to build with cl (or rather clang-cl) by using the
correct spelling for `-include` (`/FI` for cl). clang-cl and cl default
to C++11/C++14 as they support it rather than permitting an explicit
language standard.
llvm-svn: 290802
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
llvm-svn: 288690
This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI
when the current build configuration matches the configuration used to generate
the ABI lists.
In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified
to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully
the changes needed to accommodate this won't break existing build
configurations.
llvm-svn: 286789
The runtimes subdir is the new location for runtimes, we should
include it when looking for libcxxabi headers.
Differential Revision: https://reviews.llvm.org/D26363
llvm-svn: 286333
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
musl's pthread implementations use volatile types in their structs
which is not being constexpr in C++11 but is in C++14.
Differential Revision: https://reviews.llvm.org/D25491
llvm-svn: 284950
Libc++ will not build with modules enabled. In order to support an in-tree
libc++ when LLVM_ENABLE_MODULES is ON we need to explicitly disable the feature.
Unfortunately the libc++ sources are fundamentally non-modular. For example
iostream.cpp defines cout, cerr, wout, ... as char buffers instead of streams
in order to better control initialization/destruction. Not shockingly Clang
diagnoses this. Many other sources files define _LIBCPP_BUILDING_FOO macros to
provide definitions for normally inline symbols (See bind.cpp). Finally The
current module.map prohibits using <strstream> in C++11 so we can't build
strstream.cpp.
I think I can fix most of these issues but until then just disable modules.
llvm-svn: 284230
Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
holds 'public' interface libraries -- that is, libraries that both
libc++ links to and programs linked against it need to link to.
Currently this includes the ABI library and optionally -lunwind (when
LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
linker script, in order to make it possible to link C++ programs using
clang with compiler-rt runtime out-of-the-box.
Differential Revision: https://reviews.llvm.org/D25008
llvm-svn: 283659
Revert r282483 as it causes build failures due to missing symbols when
not linking to -lgcc_s (i.e. doing pure LLVM stack build). The patch can
be reintroduced when the build system is fixed to add all needed
libraries (libunwind, compiler-rt).
llvm-svn: 282524
Add the "-Wl,-z,defs" linker option that is used to prevent
underlinking. It is already used by LLVM itself but does not get
propagated into stand-alone build of libc++. This patch ensures
that the option is passed in independently of whether libc++ is built
in-tree or out-of-tree.
Patch by Lei Zhang.
Differential Revision: https://reviews.llvm.org/D24119
llvm-svn: 282483
Strip the set of flags (including debug defs, -m32) that could
be inherited from top-level LLVM build only when in-tree build is
performed. This prevents libcxx from confusingly and undesiredly
stripping user-supplied flags e.g. when performing packaging system
controlled multi-ABI build.
Otherwise, in order to perform 32-bit builds the build scripts would
have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many
different ABI flags for different targets, and it really makes no sense
to add separate CMake options for each possible -m* flag and then keep
a mapping from well-known flags to the custom CMake options.
Differential Revision: https://reviews.llvm.org/D24809
llvm-svn: 282475
builds.
On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.
This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.
This patch is based off work by Shoaib Meenai.
llvm-svn: 282449
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
When libc++experimental was originally created it was empty and therefore there
was no reason to install it. Now that the library contains
<experimental/memory_resource> and <experimental/filesystem> there is a good
reason to install it.
Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY
is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true.
llvm-svn: 280773
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
This patch enables the `cxx-benchmarks` target by default. Note that the target
still has to be manually invoked since it isn't included in the default 'make'
rule.
This patch also gets the benchmarks building w/ GCC. The build previously
required the '-stdlib=libc++' flag but upstream patches to Google Benchmark
now allow the library to build w/ libc++ and GCC.
These changes should make the benchmarks easier to build and test.
llvm-svn: 279999
Summary:
The new LLVM runtimes build directory requires some basic conventions across the runtime projects. These changes make libcxx build under the runtimes subdirectory. The general idea of the changes is that the runtimes subdirectory requires some conventions to be consistent across runtime projects.
I expect to have a few more small patches that build on this to tie up check targets and other things useful in development workflows.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXX_BUILT_STANDALONE -> LIBCXX_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23696
llvm-svn: 279151
Although libc++ only requires C++11 to build, there are other
reasons to turn on a newer dialect in the build. For example
IDE's may not highlight any C++14/C++17 in the headers when
configured for C++11. This patch add's a private option for
changing this.
llvm-svn: 278638
This change allows building both shared and static version of libc++
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23232
llvm-svn: 278068
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
From r229162:
Visual Studio's SAL extension uses a macro named __deallocate. This
macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.
Patch by Dave Lee!
llvm-svn: 275172
fstream has a switch over ios_base::seekdir which provides a defensive default
case. This seems like the right thing for fstream to do, but we need to disable
clangs warning during the build to allow this.
llvm-svn: 273092
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
Summary:
This patch changes the libc++ CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake.
Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=24322
Reviewers: danalbert, jroelofs, bcraig, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20887
llvm-svn: 271460
Petr Hosek