summaryrefslogtreecommitdiffstats
path: root/libcxx/src
Commit message (Collapse)AuthorAgeFilesLines
* Make libc++'s versioning namespace customizableEric Fiselier2018-10-301-9/+9
| | | | | | | | | | | | | | | | | Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-2/+3
| | | | | | | | | | | | | | | | | | | Summary: C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own). This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown. On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: rsmith, ckennelly, libcxx-commits, christof Differential Revision: https://reviews.llvm.org/D53120 llvm-svn: 345281
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* Temporarily Revert "Implement sized deallocation for std::allocator and ↵Eric Christopher2018-10-251-2/+2
| | | | | | | | | | friends." This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/1428 This reverts commit r345214. llvm-svn: 345239
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-241-2/+2
| | | | | | | | | | | | | | | | | | | Summary: C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own). This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown. On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: rsmith, ckennelly, libcxx-commits, christof Differential Revision: https://reviews.llvm.org/D53120 llvm-svn: 345214
* Distinguish between library and language support for aligned allocation.Eric Fiselier2018-10-111-3/+3
| | | | | | | | | | | | | | | | | | | | There are two cases: 1. The library has all it needs to provide align_val_t and the new/delete overloads needed to support aligned allocation. 2. The compiler has actually turned the language feature on. There are times where libc++ needs to distinguish between the two. This patch adds the additional macro _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1) does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the compiler has not enabled the language feature. Additionally this patch cleans up a number of other macros related to detection of aligned allocation machinery. llvm-svn: 344207
* Remove redundant null pointer check in operator deleteFangrui Song2018-10-011-5/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function If ptr is a null pointer, no action shall occur. _aligned_free on MSDN: If memblock is a NULL pointer, this function simply performs no actions. Reviewers: EricWF, mclow.lists, khng300, hotpxl Reviewed By: mclow.lists, khng300, hotpxl Subscribers: lichray, llvm-commits, hotpxl, khng300, christof, ldionne, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52401 llvm-svn: 343503
* [cxx2a] Fix warning triggered by r343285Vitaly Buka2018-09-291-1/+0
| | | | llvm-svn: 343369
* Revert r342936 "Remove redundant null pointer check in operator delete"Louis Dionne2018-09-251-3/+5
| | | | | | | | A review for the change was opened in https://reviews.llvm.org/D52401 but the change was committed before being approved by any of the code owners for libc++. llvm-svn: 342938
* Remove redundant null pointer check in operator deleteFangrui Song2018-09-251-5/+3
| | | | | | | | | | | | | | | | | | | | C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function If ptr is a null pointer, no action shall occur. _aligned_free on MSDN: If memblock is a NULL pointer, this function simply performs no actions. Reviewers: EricWF, mclow.lists Subscribers: christof, ldionne, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52401 llvm-svn: 342936
* [libc++] Remove race condition in std::asyncLouis Dionne2018-08-241-4/+1
| | | | | | | | | | | | | | | | | Summary: The state associated to the future was set in one thread (with synchronization) but read in another thread without synchronization, which led to a data race. https://bugs.llvm.org/show_bug.cgi?id=38181 rdar://problem/42548261 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51170 llvm-svn: 340608
* [libc++][C++17] Elementary string conversions for integral typesZhihao Yuan2018-08-011-0/+233
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Major QoI considerations: - The facility is backported to C++14, same as libstdc++. - Efforts have been made to minimize the header dependencies. - The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome. Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`. References: https://wg21.link/p0067r5 https://wg21.link/p0682r1 Reviewers: mclow.lists, EricWF Reviewed By: mclow.lists Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D41458 llvm-svn: 338479
* [libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne2018-08-017-8/+0
| | | | | | | | | | | | | | _LIBCPP_BUILDING_LIBRARY Summary: As suggested by Marshall in https://reviews.llvm.org/D49914 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50008 llvm-svn: 338475
* Code cleanup - change naked 'throw' expressions to call helpre function ↵Marshall Clow2018-07-301-33/+11
| | | | | | '__throw_future_error'. The behavior change is that if you build libc++ with exceptions disabled, and then use that in a program that sets the value of the future twice (for example), it will now abort instead of behaving unpredictably. llvm-svn: 338332
* Implement <filesystem>Eric Fiselier2018-07-274-516/+485
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the <filesystem> header and uses that to provide <experimental/filesystem>. Unlike other standard headers, the symbols needed for <filesystem> have not yet been placed in libc++.so. Instead they live in the new libc++fs.a library. Users of filesystem are required to link this library. (Also note that libc++experimental no longer contains the definition of <experimental/filesystem>, which now requires linking libc++fs). The reason for keeping <filesystem> out of the dylib for now is that it's still somewhat experimental, and the possibility of requiring an ABI breaking change is very real. In the future the symbols will likely be moved into the dylib, or the dylib will be made to link libc++fs automagically). Note that moving the symbols out of libc++experimental may break user builds until they update to -lc++fs. This should be OK, because the experimental library provides no stability guarantees. However, I plan on looking into ways we can force libc++experimental to automagically link libc++fs. In order to use a single implementation and set of tests for <filesystem>, it has been placed in a special `__fs` namespace. This namespace is inline in C++17 onward, but not before that. As such implementation is available in C++11 onward, but no filesystem namespace is present "directly", and as such name conflicts shouldn't occur in C++11 or C++14. llvm-svn: 338093
* Be more consistent about which bool value means an error occurredEric Fiselier2018-07-261-6/+6
| | | | llvm-svn: 338002
* Cleanup the last_write_time internalsEric Fiselier2018-07-262-17/+26
| | | | llvm-svn: 338001
* Fix attribute placement WRT extern CEric Fiselier2018-07-261-2/+2
| | | | llvm-svn: 337999
* [libc++] Add hack to allow ubsan to work w/o compiler-rt (__muloti4 is ↵Eric Fiselier2018-07-261-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | undefined) Summary: Using int128_t with UBSAN causes link errors unless compiler-rt is providing the runtime library. Specifically ubsan generates calls to __muloti4 but libgcc doesn't provide a definition. In order to avoid this, and allow users to continue using sanitized versions of libc++, this patch introduces a hack. It adds a cribbed version of the compiler-rt builtin to the libc++ filesystem sources. I don't think this approach will work in the long run, but it seems OK for now. Also see: https://bugs.llvm.org/show_bug.cgi?id=30643 https://bugs.llvm.org/show_bug.cgi?id=16404 Reviewers: mclow.lists, ldionne, rsmith, jyknight, echristo Reviewed By: echristo Subscribers: dberris, cfe-commits Differential Revision: https://reviews.llvm.org/D49828 llvm-svn: 337990
* [libc++] Follow-up to r337968: use an explicit cast as suggested by EricAlex Lorenz2018-07-251-2/+4
| | | | llvm-svn: 337984
* Fix GCC build in C++14 w/o c++14 constexprEric Fiselier2018-07-251-1/+1
| | | | llvm-svn: 337974
* Fix failing test under C++14Eric Fiselier2018-07-251-2/+2
| | | | llvm-svn: 337970
* [libc++] Follow-up to r337960: specify lambda's return type to avoidAlex Lorenz2018-07-251-1/+1
| | | | | | | | | | | -Wc++11-narrowing warning on Darwin The internal CI produced the following diagnostic: error: non-constant-expression cannot be narrowed from type 'long long' to '__darwin_suseconds_t' (aka 'int') in initializer list [-Wc++11-narrowing] struct ::timeval ConvertedTS[2] = {{TS[0].tv_sec, Convert(TS[0].tv_nsec)}, ^~~~~~~~~~~~~~~~~~~~~~ llvm-svn: 337968
* Make <experimental/filesystem> compile with gcc 4.8.5Eric Fiselier2018-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Victor Zverovich. This fixes an error when compiling `<experimental/filesystem>` with gcc 4.8.5: ``` .../libcxx/src/experimental/filesystem/filesystem_common.h:137:34: error: redeclaration ‘T std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T = bool]’ d iffers in ‘constexpr’ constexpr bool error_value<bool>() { ^ .../libcxx/src/experimental/filesystem/filesystem_common.h:133:3: error: from previous declaration ‘T std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T = bool]’ T error_value(); ^ ``` Reviewed as https://reviews.llvm.org/D49813 llvm-svn: 337962
* [libc++] Use __int128_t to represent file_time_type.Eric Fiselier2018-07-254-188/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ``file_time_type`` time point is used to represent the write times for files. Its job is to act as part of a C++ wrapper for less ideal system interfaces. The underlying filesystem uses the ``timespec`` struct for the same purpose. However, the initial implementation of ``file_time_type`` could not represent either the range or resolution of ``timespec``, making it unsuitable. Fixing this requires an implementation which uses more than 64 bits to store the time point. I primarily considered two solutions: Using ``__int128_t`` and using a arithmetic emulation of ``timespec``. Each has its pros and cons, and both come with more than one complication. However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change. Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information. Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF Reviewed By: EricWF Subscribers: christof, K-ballo, cfe-commits, BillyONeal Differential Revision: https://reviews.llvm.org/D49774 llvm-svn: 337960
* [windows] Fix warning about comparing ints of different signsMartin Storsjo2018-07-251-2/+3
| | | | | | | | | | | | | | This fixes a warning like this: warning: comparison of integers of different signs: 'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD' (aka 'unsigned long') [-Wsign-compare] if (*__key == FLS_OUT_OF_INDEXES) ~~~~~~ ^ ~~~~~~~~~~~~~~~~~~ Differential Revision: https://reviews.llvm.org/D49782 llvm-svn: 337946
* Fix bugs in create_directory implementation.Eric Fiselier2018-07-251-2/+4
| | | | | | | | | | | | | | Libc++ was incorrectly reporting an error when the target of create_directory already exists, but was not a directory. This behavior is not specified in the most recent standard, which says no error should be reported. Additionally, libc++ failed to report an error when the attribute directory path didn't exist or didn't name a directory. This has been fixed as well. Although it's not clear if we should call status or symlink_status on the attribute directory. This patch chooses to still call status. llvm-svn: 337888
* Make <experimental/filesystem> explicitly require C++11.Eric Fiselier2018-07-251-2/+0
| | | | | | | | | | | | | | Previously the <experimental/filesystem> didn't guard its contents in any dialect. However, the implementation implicitly requires at least C++11, and the tests have always been marked unsupported in C++03. This patch puts a header guard around the contents to avoid exposing them before C++11. Additionally, it replaces all of the usages of _NOEXCEPT or _LIBCPP_CONSTEXPR with the keyword directly, since we can expect the compiler to implement those by now. llvm-svn: 337884
* Ensure path::iterator and PathParser share the same enumeration values.Eric Fiselier2018-07-251-11/+10
| | | | | | | | | | | | To avoid exposing implementation details, path::iterator and PathParser both implicitly used the same set of values to represent the state, but they were defined twice. This could have lead to a mismatch occuring. This patch moves all of the parser state values into the filesystem header and changes PathParser to use those value to avoid this. llvm-svn: 337883
* Handle DT_UNKNOWN correctly during directory iteration.Eric Fiselier2018-07-231-1/+4
| | | | | | | | | | Unlike stat and lstat, where unknown really means we know it's something weird, during directory iteration DT_UNKNOWN simply means that the underlying FS doesn't support the dirent::dt_type field. This patch fixes libc++ to correctly set the cache to empty when DT_UNKNOWN is reported. llvm-svn: 337768
* Recommit "Use possibly cached directory entry values when performing ↵Eric Fiselier2018-07-231-3/+4
| | | | | | | | | | | | | recursive directory iteration." The initial patch didn't correctly handle systems when the dirent struct didn't provide the d_type member. Specifically it set the cache to the incorrect state, and claimed it was partially populated. The updated version of this change correctly handles setting up the cache when the file type is not known (aka file_type::none). llvm-svn: 337765
* Revert "Use possibly cached directory entry values when performing recursive ↵Eric Fiselier2018-07-231-2/+2
| | | | | | | | directory iteration." This reverts commit 04ce4aef00d3ee508327f6cf7bf1b1d200ab6238. llvm-svn: 337749
* Cleanup unnecessary conversions in filesystem.Eric Fiselier2018-07-231-2/+2
| | | | llvm-svn: 337685
* Cleanup name qualification in the filesystem internals.Eric Fiselier2018-07-233-118/+118
| | | | | | | | In most cases there is no reason why the filesystem internals use the qualifier std:: or _VSTD::. This patch removes the unneeded qualifiers, making the sources files more consistent llvm-svn: 337684
* Use possibly cached directory entry values when performing recursive ↵Eric Fiselier2018-07-231-2/+2
| | | | | | directory iteration. llvm-svn: 337669
* Work around various GCC 4.9 build errorsEric Fiselier2018-07-232-9/+14
| | | | llvm-svn: 337665
* Implement filesystem_error::what() and improve reporting.Eric Fiselier2018-07-233-373/+494
| | | | | | | | | | | This patch implements the `what()` for filesystem errors. The message includes the 'what_arg', any paths that were specified, and the error code message. Additionally this patch refactors how errors are created, making it easier to report them correctly. llvm-svn: 337664
* Workaround bug in GCC trunk.Eric Fiselier2018-07-221-4/+4
| | | | | | | | | | For some reason GCC ToT is failing to deduce the auto type for a static data member from its initializer in some cases. Though I'm sure the bug will be short lived, there is a trivial workaround for it. So we might as well get the bot passing again. llvm-svn: 337661
* Harden copy_file even more.Eric Fiselier2018-07-221-5/+7
| | | | | | | | | | | This patch removes the O_CREAT open flag when we first attempt to open the destination file but we expect it to already exist. This theoretically avoids the possibility that it was removed between when we first stat'ed it, and when we attempt to open it. llvm-svn: 337659
* Implement a better copy_file.Eric Fiselier2018-07-221-79/+279
| | | | | | | | | | | | | | | | | | | | This patch improves both the performance, and the safety of the copy_file implementation. The performance improvements are achieved by using sendfile on Linux and copyfile on OS X when available. The TOCTOU hardening is achieved by opening the source and destination files and then using fstat to check their attributes to see if we can copy them. Unfortunately for the destination file, there is no way to open it without accidentally creating it, so we first have to use stat to determine if it exists, and if we should copy to it. Then, once we're sure we should try to copy, we open the dest file and ensure it names the same entity we previously stat'ed. llvm-svn: 337649
* adjust incorrect commentEric Fiselier2018-07-201-1/+2
| | | | llvm-svn: 337532
* Use _LIBCPP_UNREACHABLE to convince GCC that non-void functions actually ↵Eric Fiselier2018-07-201-2/+2
| | | | | | always return llvm-svn: 337519
* cleanup test assertion inside libraryEric Fiselier2018-07-201-6/+0
| | | | llvm-svn: 337517
* [libc++] Implement Directory Entry Caching -- Sort of.Eric Fiselier2018-07-203-202/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements directory_entry caching *almost* as specified in P0317r1. However, I explicitly chose to deviate from the standard as I'll explain below. The approach I decided to take is a fully caching one. When `refresh()` is called, the cache is populated by calls to `stat` and `lstat` as needed. During directory iteration the cache is only populated with the `file_type` as reported by `readdir`. The cache can be in the following states: * `_Empty`: There is nothing in the cache (likely due to an error) * `_IterSymlink`: Created by directory iteration when we walk onto a symlink only the symlink file type is known. * `_IterNonSymlink`: Created by directory iteration when we walk onto a non-symlink. Both the regular file type and symlink file type are known. * `_RefreshSymlink` and `_RefreshNonSymlink`: A full cache created by `refresh()`. This case includes dead symlinks. * `_RefreshSymlinkUnresolved`: A partial cache created by refresh when we fail to resolve the file pointed to by a symlink (likely due to permissions). Symlink attributes are cached, but attributes about the linked entity are not. As mentioned, this implementation purposefully deviates from the standard. According to some readings of the specification, and the Windows filesystem implementation, the constructors and modifiers which don't pass an `error_code` must throw when the `directory_entry` points to a entity which doesn't exist. or when attribute resolution fails for another reason. @BillyONeal has proposed a more reasonable set of requirements, where modifiers other than refresh ignore errors. This is the behavior libc++ currently implements, with the expectation some form of the new language will be accepted into the standard. Some additional semantics which differ from the Windows implementation: 1. `refresh` will not throw when the entry doesn't exist. In this case we can still meet the functions specification, so we don't treat it as an error. 2. We don't clear the path name when a constructor fails via refresh (this will hopefully be changed in the standard as well). It should be noted that libstdc++'s current implementation has the same behavior as libc++, except for point (2). If the changes to the specification don't get accepted, we'll be able to make the changes later. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Reviewers: mclow.lists, gromer, ldionne, aaron.ballman Subscribers: BillyONeal, christof, cfe-commits Differential Revision: https://reviews.llvm.org/D49530 llvm-svn: 337516
* Fix PR38160 - init_priority attribute not supported by GCC on Apple.Eric Fiselier2018-07-161-1/+12
| | | | | | | | This patch guards the use of __attribute__((init_priority(101))) within memory_resource.cpp when building with compilers that don't support it. Specifically GCC on Apple platforms, and MSVC. llvm-svn: 337205
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Note that this commit had originally been applied in r336369 and then reverted in r336382 because of unforeseen problems. Both of these problems have now been fixed. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, erikvanderpoel Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336866
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-051-2/+2
| | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY" This reverts commit r336369. The commit had two problems: 1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the dylib and the check-cxx-abilist failing. 2. The LLDB tests started failing because they undefine `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and fix the tests before we can go forward with this change. llvm-svn: 336382
* [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-051-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Reviewers: EricWF Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336369
* Configure ELAST for MinGWPirama Arumuga Nainar2018-06-281-2/+2
| | | | | | | | | | | | | | Summary: Use _LIBCPP_MSVCRT_LIKE while configuring ELAST, so MinGW gets the same configuration as MSVC. Reviewers: compnerd, srhines, danalbert, mstorsjo Subscribers: christof, ldionne, cfe-commits Differential Revision: https://reviews.llvm.org/D48731 llvm-svn: 335916
* Fix embarrasing typo in uncaught_exceptions. Update tests to really test ↵Marshall Clow2018-05-291-1/+1
| | | | | | this. Thanks to Peter Klotz for calling my attention to this. llvm-svn: 333467
OpenPOWER on IntegriCloud