summaryrefslogtreecommitdiffstats
path: root/libcxx/src
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx] [Windows] Store the lconv struct returned from localeconv in locale_tMartin Storsjö2020-02-041-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes using non-default locales, which currently can crash when e.g. formatting numbers. Within the localeconv_l function, the per-thread locale is temporarily changed with __libcpp_locale_guard, then localeconv() is called, returning an lconv * struct pointer. When localeconv_l returns, the __libcpp_locale_guard dtor restores the per-thread locale back to the original. This invalidates the contents of the earlier returned lconv struct, and all C strings that are pointed to within it are also invalidated. Thus, to have an actually working localeconv_l function, the function needs to allocate some sort of storage for the returned contents, that stays valid for as long as the caller needs to use the returned struct. Extend the libcxx/win32 specific locale_t class with storage for a deep copy of a lconv struct, and change localeconv_l to take a reference to the locale_t, to allow it to store the returned lconv struct there. This works fine for libcxx itself, but wouldn't necessarily be right for a caller that uses libcxx's localeconv_l function. This fixes around 11 of libcxx's currently failing tests on windows. Differential Revision: https://reviews.llvm.org/D69505 (cherry picked from commit 7db4f2c6945a24a7d81dad3362700353e2ec369e)
* [libcxx] [Windows] Make a more proper implementation of strftime_l for mingw ↵Martin Storsjö2020-01-141-0/+8
| | | | | | | | | | | | | | | | with msvcrt.dll This also makes this function consistent with the rest of the libc++ provided fallbacks. The locale support in msvcrt.dll is very limited anyway; it can only be configured processwide, not per thread, and it only seems to support the locales "C" and "" (the user set locale), so it's hard to make any meaningful automatic test for it. But manually tested, this change does make time formatting locale code in libc++ output times in the user requested format, when using locale "". Differential Revision: https://reviews.llvm.org/D69554
* Revert "[libc++] Explicitly enumerate std::string external instantiations."Oliver Stannard2020-01-131-2/+2
| | | | | | | This is causing failures for multiple buildbots and bootstrap builds, details at https://reviews.llvm.org/rG61bd1920. This reverts commit 61bd19206f61ace4b007838a2ff8884a13ec0374.
* [libc++] Explicitly enumerate std::string external instantiations.Eric Fiselier2020-01-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | The external instantiation of std::string is a problem for libc++. Additions and removals of inline functions in string can cause ABI breakages, including introducing new symbols. This patch aims to: (1) Make clear which functions are explicitly instatiated. (2) Prevent new functions from being accidentally instantiated. (3) Allow a migration path for adding or removing functions from the explicit instantiation over time. Although this new formulation is uglier, it is preferable from a maintainability and readability standpoint because it explicitly enumerates the functions we've chosen to expose in our ABI. Changing this list is non-trivial and requires thought and planning. (3) is achieved by making it possible to control the extern template declaration separately from it's definition. Meaning we could add a new definition to the dylib, wait for it to roll out, then add the extern template declaration to the header. Similarly, we could remove existing extern template declarations while still keeping the definition to prevent ABI breakages.
* [libcxx{,abi}] Emit deplibs only when detected by CMakeMichał Górny2019-12-0210-10/+10
| | | | | | | | This is a followup to 35bc5276ca3. It fixes the dependent libs usage in libcxx and libcxxabi to link pthread and rt libraries only if CMake detects them, rather than based on explicit platform blacklist. Differential Revision: https://reviews.llvm.org/D70888
* [libc++] Validate the entire regex is consumedMark de Wever2019-11-091-0/+2
| | | | | | | This change would have warned about the bug found in D62451. No unit tests since the exception should never throw. Differential Revision: https://reviews.llvm.org/D62452
* [libcxx][NFC] Strip trailing whitespace, fix typo.Stephan T. Lavavej2019-10-236-12/+12
|
* [libc++][NFC] Remove excess trailing newlines from most filesCasey Carter2019-10-232-2/+0
| | | | Testing git commit access.
* [libc++] Move the linker script generation step to CMakeLouis Dionne2019-10-081-28/+4
| | | | | | | | | | | | | | | | | | Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
* [libc++] Make sure we link all system libraries into the benchmarksLouis Dionne2019-10-081-63/+2
| | | | | | | | | It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
* [libc++] TAKE 2: Make system libraries PRIVATE dependencies of libc++Louis Dionne2019-10-081-14/+14
| | | | | | | | | | We tried doing that previously (in r373487) and failed (reverted in r373506) because the benchmarks needed to link against system libraries and relied on libc++'s dependencies being propagated. Now that this has been fixed (in r374053), this commit marks the system libraries as PRIVATE dependencies of libc++. llvm-svn: 374056
* [libc++] Guard cxx_experimental settings behind ↵Alex Langford2019-10-041-6/+6
| | | | | | | | | | LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY If you explicitly set LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY to OFF, your project will fail to configure because the cxx_experimental target doesn't exist. llvm-svn: 373809
* [libc++] Localize common build flags into a single CMake functionLouis Dionne2019-10-041-20/+10
| | | | | | | | Also, set those flags for the cxx_experimental target. Otherwise, cxx_experimental doesn't build properly when neither the static nor the shared library is compiled (yes, that is a weird setup). llvm-svn: 373808
* [libc++] Move more CMake flags to per-target definitionsLouis Dionne2019-10-041-0/+6
| | | | | | | This daily refactoring tackles flags related to modules, exceptions and RTTI. llvm-svn: 373767
* [libc++] Add a per-target flag to include the generated config_siteLouis Dionne2019-10-031-0/+2
| | | | | | | | | | | This allows propagating the include automatically to targets that depend on one of the libc++ targets such as the benchmarks. Note that the GoogleBenchmark build itself still needs to manually specify the -include, since I don't know of any way to have an external project link against one of the libc++ targets (which would propagate the -include automatically). llvm-svn: 373631
* [libc++] Use functions instead of global variables to set libc++ build flagsLouis Dionne2019-10-021-29/+4
| | | | | | | | This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
* [libc++] Use a function to set warning flags per targetLouis Dionne2019-10-021-0/+2
| | | | | | | | | | This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
* [libc++] Revert to using PUBLIC instead of PRIVATE when linking system libsLouis Dionne2019-10-021-14/+14
| | | | | | | | It turns out the benchmarks need to link against those libraries explicitly too, so CMake's propagation of PUBLIC dependencies is used. llvm-svn: 373506
* [libc++] Use PRIVATE instead of PUBLIC when linking against system libsLouis Dionne2019-10-021-14/+14
| | | | llvm-svn: 373487
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-262-4/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. This was previously committed as r372777 and reverted in r372832 due to the commit breaking LLVM's build in C++14 mode. This issue has now been addressed. Reviewers: mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372983
* Revert r372777: [libc++] Implement LWG 2510 and its follow-upsIlya Biryukov2019-09-252-4/+4
| | | | | | | | | | | | This also reverts: - r372778: [libc++] Implement LWG 3158 - r372782: [libc++] Try fixing tests that fail on GCC 5 and older - r372787: Purge mentions of GCC 4 from the test suite Reason: the change breaks compilation of LLVM with libc++, for details see http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html llvm-svn: 372832
* [libc++] Implement LWG 2510Louis Dionne2019-09-242-4/+4
| | | | | | | | | | | | | | | | | | | Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372777
* Only initialize the streams cout/wcout/cerr/wcerr etc once, rather than any ↵Marshall Clow2019-09-131-2/+17
| | | | | | time Init::Init is called. Fixes PR#43300 llvm-svn: 371864
* Fix build in C++20Eric Fiselier2019-09-131-2/+2
| | | | llvm-svn: 371863
* [libc++] Only build with -fvisibility=hidden on ClangLouis Dionne2019-09-041-1/+7
| | | | | | | | | | | | | The visibility annotations in libc++ are not quite right for GCC, which results in symbols not being exported when -fvisibility=hidden is used. To fix the GCC build bots, this commit reverts to the previous state of not building with hidden visibility on GCC. In the future, we can build with hidden visibility all the time and export symbols explicitly using a list. See https://llvm.org/D66970 for one take at this. llvm-svn: 370926
* [libc++] Fix directory_iterator compilation on Win32Nico Weber2019-08-311-6/+6
| | | | | | | | | | | | This patch fixes some typos and other small errors in directory_iterator.cpp that prevented this file from being compiled for Win32. Patch by Stefan Schmidt <thrimbor.github@gmail.com>! Differential Revision: https://reviews.llvm.org/D66986 llvm-svn: 370599
* Fix missing __muloti4 function with UBSANEric Fiselier2019-08-211-1/+1
| | | | llvm-svn: 369483
* Fix thread comparison by making sure we never pass our special 'not a ↵Marshall Clow2019-08-141-1/+1
| | | | | | thread' value to the underlying implementation. Fixes PR#42918. llvm-svn: 368916
* Rework recursive_timed_mutex so that it uses __thread_id instead of using ↵Marshall Clow2019-08-141-6/+6
| | | | | | the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895 llvm-svn: 368867
* [libc++] Always build with -fvisibility=hiddenLouis Dionne2019-08-132-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This avoids symbols being accidentally exported from the dylib when they shouldn't. The next step is to use a pragma to apply hidden visibility to all declarations (unless otherwise specified), which will allow us to drop the per-declaration hidden visibility attributes we currently have. This also has the nice side effect of making sure the dylib exports the same symbols regardless of the optimization level. PR38138 Reviewers: EricWF, mclow.lists Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62868 llvm-svn: 368703
* [libc++] Take 2: Integrate the PSTL into libc++Louis Dionne2019-08-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. The first attempt to commit this failed because it exposed a bug in the tests for modules. Now that this has been fixed, it should be safe to commit this. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 367903
* [runtimes] Don't depend on libpthread on AndroidYi Kong2019-07-2210-10/+10
| | | | | | | | | | r362048 added support for ELF dependent libraries, but broke Android build since Android does not have libpthread. Remove the dependency on the Android build. Differential Revision: https://reviews.llvm.org/D65098 llvm-svn: 366734
* Revert "[libc++] Integrate the PSTL into libc++"Louis Dionne2019-07-191-9/+0
| | | | | | | This reverts r366593, which caused unforeseen breakage on the build bots. I'm reverting until the problems have been figured out and fixed. llvm-svn: 366603
* [libc++] Integrate the PSTL into libc++Louis Dionne2019-07-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. Reviewers: rodgert, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 366593
* build: use multiple `install` rather than building up a listSaleem Abdulrasool2019-07-091-12/+20
| | | | | | | | Rather than building up a list to iterate over later, just create multiple install commands based on the configuration. This makes it easier to see what is getting installed and allows for the install handling to be centralised. NFC llvm-svn: 365562
* Make ~mutex and ~condition_variable trivial on Windows.Eric Fiselier2019-07-073-4/+48
| | | | | | | | | The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy are already NOPs, so this optimization is safe to perform. See r365273 and PR27658 for more information. llvm-svn: 365281
* Fix PR27658 - Make ~mutex trivial when possible.Eric Fiselier2019-07-073-4/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently std::mutex has a constexpr constructor, but a non-trivial destruction. The constexpr constructor is required to ensure the construction of a mutex with static storage duration happens at compile time, during constant initialization, and not during dynamic initialization. This means that static mutex's are always initialized and can be used safely during dynamic initialization without the "static initialization order fiasco". A trivial destructor is important for similar reasons. If a mutex is used during dynamic initialization it might also be used during program termination. If a static mutex has a non-trivial destructor it will be invoked during termination. This can introduce the "static deinitialization order fiasco". Additionally, function-local statics emit a guard variable around non-trivially destructible types. This results in horrible codegen and adds a runtime cost to every call to that function. non-local static's also result in slightly worse codegen but it's not as big of a problem. Example codegen can be found here: https://goo.gl/3CSzbM Note: This optimization is not safe with every pthread implementation. Some implementations allocate on the first call to pthread_mutex_lock and free the allocation in pthread_mutex_destroy. Also, changing the triviality of the destructor is not an ABI break. At least to the best of my knowledge :-) llvm-svn: 365273
* [libc++] Avoid using timespec when it might not be availableMikhail Maltsev2019-06-212-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The type timespec is unconditionally used in __threading_support. Since the C library is only required to provide it in C11, this might cause problems for platforms with external thread porting layer (i.e. when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11 C libraries. In our downstream port of libc++ we used to provide a definition of timespec in __external_threading, but this solution is not ideal because timespec is not a reserved name. This patch renames timespec into __libcpp_timespec_t in the thread-related parts of libc++. For all cases except external threading this type is an alias for ::timespec (and no functional changes are intended). In case of external threading it is expected that the __external_threading header will either provide a similar typedef (if timespec is available in the vendor's C library) or provide a definition of __libcpp_timespec_t compatible with POSIX timespec. Reviewers: ldionne, mclow.lists, EricWF Reviewed By: ldionne Subscribers: dexonsmith, libcxx-commits, christof, carwil Tags: #libc Differential Revision: https://reviews.llvm.org/D63328 llvm-svn: 364012
* Fix a '>= 0' test on unsigned that I inadvertantly introduced. Now correctly ↵Marshall Clow2019-06-171-1/+1
| | | | | | '!= 0'. Thanks to Arthur for the catch llvm-svn: 363557
* Recommit r362649, which was reverted in r262680 because of bugs in ↵Marshall Clow2019-06-101-103/+37
| | | | | | std::to_chars (which have now been fixed). Speedup to_string and to_wstring for integers using stack buffer and SSO llvm-svn: 363003
* [libc++] Fix leading zeros in std::to_charsZhihao Yuan2019-06-101-116/+44
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: It is a bugfix proposal for https://bugs.llvm.org/show_bug.cgi?id=42166. `std::to_chars` appends leading zeros if input 64-bit value has 9, 10 or 11 digits. According to documentation `std::to_chars` must not append leading zeros: https://en.cppreference.com/w/cpp/utility/to_chars Changeset should not affect `std::to_chars` performance: http://quick-bench.com/CEpRs14xxA9WLvkXFtaJ3TWOVAg Unit test that `std::from_chars` supports compatibility for both `std::to_chars` outputs (previous and fixed one) already exists: https://github.com/llvm-mirror/libcxx/blob/1f60111b597e5cb80a4513ec86f79b7e137f7793/test/std/utilities/charconv/charconv.from.chars/integral.pass.cpp#L63 Reviewers: lichray, mclow.lists, ldionne, EricWF Reviewed By: lichray, mclow.lists Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D63047 llvm-svn: 362967
* Revert "Speedup to_string and to_wstring for integers using stack buffer and ↵Vlad Tsyrklevich2019-06-061-37/+103
| | | | | | | | | | SSO." This reverts commit 7ce7110e6d964778141c0866488e154b1ce73d69, it was causing sanitizer bot failures due to changing behavior of std::to_string(). See https://reviews.llvm.org/D59178#1532023 llvm-svn: 362680
* Speedup to_string and to_wstring for integers using stack buffer and SSO. ↵Marshall Clow2019-06-051-103/+37
| | | | | | Reviewed as https://reviews.llvm.org/D59178 Thanks to ivafanas for all his work on this patch. llvm-svn: 362649
* No longer reject inputs when using a locale that has grouping information ↵Marshall Clow2019-06-041-1/+3
| | | | | | _and_ the input has no grouping characters at all. We continue to reject cases when the input has grouping characters in the wrong place. Fixes PR#28704 llvm-svn: 362508
* [libcxx] Use libtool when merging archives on Apple platformsPetr Hosek2019-06-021-0/+4
| | | | | | | | | | ar doesn't produce the correct results when used for linking static archives on Apple platforms, so instead use libtool -static which is the official way to build static archives on those platforms. Differential Revision: https://reviews.llvm.org/D62770 llvm-svn: 362311
* [runtimes] Use _LIBCPP_HAS_COMMENT_LIB_PRAGMA in all relevant filesPetr Hosek2019-05-302-2/+2
| | | | | | These two sources were omitted in r362055. llvm-svn: 362061
* [runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek2019-05-308-8/+8
| | | | | | | | | This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
* [runtimes] Support ELF dependent libraries featurePetr Hosek2019-05-3010-0/+41
| | | | | | | | | | | | | | | | | | | As of r360984, LLD supports dependent libraries feature for ELF. libunwind, libc++abi and libc++ have library dependencies: libdl librt and libpthread, which means that when libunwind and libc++ are being statically linked (using -static-libstdc++ flag), user has to manually specify -ldl -lpthread which is onerous. This change includes the lib pragma to specify the library dependencies directly in the source that uses those libraries. This doesn't make any difference when using linkers that don't support dependent libraries. However, when using LLD that has dependent libraries feature, users no longer have to manually specifying library dependencies when using static linking, linker will pick the library automatically. Differential Revision: https://reviews.llvm.org/D62090 llvm-svn: 362048
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-221-3/+3
| | | | | | | | | | | | | | | | | include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
* Speculative fix for std stream destruction order on Windows.Eric Fiselier2019-05-221-0/+21
| | | | | | | | | | | | | | | The MSVC CRT uses TLS storage to implement per-thread locales. This storage gets freed during program termination, and if we attempt to do any io operations (like flushing the std streams) after this occurs the program may abort. This patch is a speculative fix for that issue. The fix tries forcing the initialization of the locale TLS before initializing the std streams. This should mean that the TLS is freed after we destroy the streams. llvm-svn: 361348
OpenPOWER on IntegriCloud