| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This is causing failures for multiple buildbots and bootstrap builds,
details at https://reviews.llvm.org/rG61bd1920.
This reverts commit 61bd19206f61ace4b007838a2ff8884a13ec0374.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes unneeded zero initialization of string data.
For example, given the below code:
void Init(void *mem) {
new (mem) std::string("Hello World");
}
Assembly before:
Init(void*):
xorps xmm0, xmm0
movups xmmword ptr [rdi], xmm0
mov qword ptr [rdi + 16], 0
mov byte ptr [rdi], 22
movabs rax, 8022916924116329800
mov qword ptr [rdi + 1], rax
mov dword ptr [rdi + 8], 1684828783
mov byte ptr [rdi + 12], 0
ret
Assembly after:
Init():
mov byte ptr [rdi], 22
movabs rax, 8022916924116329800
mov qword ptr [rdi + 1], rax
mov dword ptr [rdi + 8], 1684828783
mov byte ptr [rdi + 12], 0
ret
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D70621
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
|
|
|
|
| |
https://reviews.llvm.org/D68623. Thanks to mvels for the patch.
|
|
|
|
|
|
|
|
|
| |
With the upcoming introduction of iterator concepts in ranges,
the meaning of "__is_contiguous_iterator" changes drastically.
Currently we intend it to mean "does it have this iterator category",
but it could now also mean "does it meet the requirements of this
concept", and these can be different.
|
|
|
|
|
|
|
| |
This function has the same behavior as the now-standand std::to_address.
Re-using the name makes the behavior more clear, and in the future it
will allow us to correctly get the raw pointer for user provided pointer
types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D68276
This is a non trivial win for externally templated assignment operator.
x86 without tail call (current libc++)
0000000000000000 <std::string::operator=(std::string const&)>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 53 push %rbx
5: 50 push %rax
6: 48 89 fb mov %rdi,%rbx
9: 48 39 f7 cmp %rsi,%rdi
c: 74 17 je 25 <std::string::operator=(std::string const&)+0x25>
e: 0f b6 56 17 movzbl 0x17(%rsi),%edx
12: 84 d2 test %dl,%dl
14: 79 07 jns 1d <std::string::operator=(std::string const&)+0x1d>
16: 48 8b 56 08 mov 0x8(%rsi),%rdx
1a: 48 8b 36 mov (%rsi),%rsi
1d: 48 89 df mov %rbx,%rdi
20: e8 00 00 00 00 callq 25 <std::string::operator=(std::string const&)+0x25>
25: 48 89 d8 mov %rbx,%rax
28: 48 83 c4 08 add $0x8,%rsp
2c: 5b pop %rbx
2d: 5d pop %rbp
2e: c3 retq
After:
0000000000000000 <std::string::operator=(std::string const&)>:
0: 48 39 f7 cmp %rsi,%rdi
3: 74 14 je 19 <std::string::operator=(std::string const&)+0x19>
5: 0f b6 56 17 movzbl 0x17(%rsi),%edx
9: 84 d2 test %dl,%dl
b: 79 07 jns 14 <std::string::operator=(std::string const&)+0x14>
d: 48 8b 56 08 mov 0x8(%rsi),%rdx
11: 48 8b 36 mov (%rsi),%rsi
14: e9 00 00 00 00 jmpq 19 <std::string::operator=(std::string const&)+0x19>
19: 48 89 f8 mov %rdi,%rax
1c: c3 retq
Benchmark (pending per https://reviews.llvm.org/D67667)
```
BM_StringAssignStr_Empty_Opaque 6.23ns ± 0% 5.19ns ± 0% -16.70% (p=0.016 n=5+4)
BM_StringAssignStr_Empty_Transparent 5.86ns ± 0% 5.14ns ± 0% -12.24% (p=0.008 n=5+5)
BM_StringAssignStr_Small_Opaque 8.79ns ± 1% 7.69ns ± 0% -12.53% (p=0.008 n=5+5)
BM_StringAssignStr_Small_Transparent 9.44ns ± 0% 8.00ns ± 0% -15.26% (p=0.008 n=5+5)
BM_StringAssignStr_Large_Opaque 25.2ns ± 0% 24.3ns ± 0% -3.50% (p=0.008 n=5+5)
BM_StringAssignStr_Large_Transparent 23.6ns ± 0% 22.5ns ± 0% -4.76% (p=0.008 n=5+5)
BM_StringAssignStr_Huge_Opaque 319ns ± 5% 317ns ± 5% ~ (p=0.690 n=5+5)
BM_StringAssignStr_Huge_Transparent 319ns ± 5% 317ns ± 5% ~ (p=0.421 n=5+5)
BM_StringAssignAsciiz_Empty_Opaque 7.41ns ± 0% 7.77ns ± 0% +4.89% (p=0.008 n=5+5)
BM_StringAssignAsciiz_Empty_Transparent 7.54ns ± 3% 7.30ns ± 0% -3.24% (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Opaque 9.87ns ± 0% 10.24ns ± 1% +3.76% (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Transparent 10.4ns ± 1% 9.8ns ± 2% -5.78% (p=0.008 n=5+5)
BM_StringAssignAsciiz_Large_Opaque 30.1ns ± 0% 30.1ns ± 0% ~ (p=0.167 n=5+5)
BM_StringAssignAsciiz_Large_Transparent 27.1ns ± 0% 27.4ns ± 0% +0.92% (p=0.016 n=4+5)
BM_StringAssignAsciiz_Huge_Opaque 383ns ± 4% 382ns ± 4% ~ (p=0.548 n=5+5)
BM_StringAssignAsciiz_Huge_Transparent 375ns ± 0% 380ns ± 0% +1.37% (p=0.029 n=4+4)
BM_StringAssignAsciizMix_Opaque 14.0ns ± 0% 14.0ns ± 0% ~ (p=0.881 n=5+5)
BM_StringAssignAsciizMix_Transparent 13.7ns ± 1% 13.8ns ± 0% ~ (p=0.056 n=5+5)
```
llvm-svn: 374137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is effectively a revert of r344616, which was a partial fix for
PR38964 (compilation of <string> with GCC in C++03 mode). However, that
configuration is explicitly not supported anymore and that partial fix
breaks compilation with Clang when per-TU insulation is provided.
PR42676
rdar://52899715
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64941
llvm-svn: 366567
|
|
|
|
|
|
| |
It's incredibly annoying when trying to create diffs
llvm-svn: 361981
|
|
|
|
|
|
| |
https://reviews.llvm.org/D61954
llvm-svn: 361201
|
|
|
|
|
|
| |
These are just rebranded 'operator[]', and should be noexcept like it is.
llvm-svn: 356435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically,
I thought that if a debug violation aborted, we could only test one violation per file. This made
it impossible to test debug mode. Which throwing behavior we could test more!
However, the throwing approach didn't work either, since there are debug violations underneath noexcept
functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug
mode was off.
Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was
viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst
changing the behavior of their program.
This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style
death tests.
Reviewers: mclow.lists, ldionne, thomasanderson
Reviewed By: ldionne
Subscribers: christof, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D59166
llvm-svn: 356417
|
|
|
|
| |
llvm-svn: 356140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
| |
Fundamentals 2 for C++20. Reviewed as https://reviews.llvm.org/D55532
llvm-svn: 349178
|
|
|
|
| |
llvm-svn: 348828
|
|
|
|
| |
llvm-svn: 347789
|
|
|
|
|
|
|
| |
This attribute should appear only on the first declaration. This
patch cleans up <string> by removing the attribute on redeclarations.
llvm-svn: 347608
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds an implementation of __resize_default_init as
described in P1072R2. Additionally, it uses it in filesystem to
demonstrate its intended utility.
Once P1072 lands, or if it changes it's interface, I will adjust
the internal libc++ implementation to match.
llvm-svn: 347589
|
|
|
|
|
|
|
| |
Otherwise, Clang complains about internal_linkage not being applied to the
first declaration of the operator (and rightfully so).
llvm-svn: 347400
|
|
|
|
|
|
|
|
|
|
|
|
| |
r347395 changed the ABI list on Linux, but two of those symbols are still
being exported from the shared object:
_ZSt18make_exception_ptrINSt3__112future_errorEESt13exception_ptrT_
_ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EERKS9_PKS6_
This commit makes sure those symbols are not exported, as they should be.
llvm-svn: 347399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit marks a few functions as hidden and removes them from the ABI list
on Linux such that libc++ can be built with -fvisibility=hidden. The functions
marked as hidden by this patch were exported from the shared object only
because they were implicitly instantiated function templates. It is safe
to stop exporting those symbols from the shared object because nobody could
actually depend on them: implicit instantiations are not taken from shared
objects.
The symbols removed in this commit are basically the same that had been
removed in https://reviews.llvm.org/D53868, but that patch had to be reverted
because it broke the build (because the functions were not marked as hidden
like this patch does).
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54639
llvm-svn: 347395
|
|
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D52240
llvm-svn: 344616
|
|
|
|
|
|
| |
feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955
llvm-svn: 342073
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an always_inline function is used prior to the functions definition,
the compiler may not be able to inline it as requested by the attribute.
GCC flags the `basic_string(CharT const*)` function as one such example.
This patch supresses the warning, and the problem, by moving the
definition of the string constructor to the inline declaration.
This ensures the body is available when it is first ODR used.
llvm-svn: 337235
|
|
|
|
| |
llvm-svn: 336132
|
|
|
|
|
|
| |
catch block and call to terminate in string's move assignment. Thanks to Howard for the 'catch'.
llvm-svn: 333435
|
|
|
|
| |
llvm-svn: 328064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shrink_to_fit() ends up doing a lot work to get information that we
already know since we just called clear(). This change seems concise
enough to be worth the couple extra lines and my benchmarks show that it
is indeed a pretty decent win. It looks like the same thing is going on
twice in __copy_assign_alloc(), but I didn't want to go overboard since
this is my first contribution to llvm/libc++.
Patch by Timothy VanSlyke!
Differential Revision: https://reviews.llvm.org/D41976
llvm-svn: 327064
|
|
|
|
| |
llvm-svn: 324569
|
|
|
|
|
|
| |
sizeof(T)>sizeof(long long)'. We were mishandling the small-string optimization calculations for very large 'characters'. This may be an ABI change (change the size of) strings of very large 'characters', but since they never worked, I'm not too concerned.
llvm-svn: 324531
|
|
|
|
|
|
| |
mandated by P0767.
llvm-svn: 323071
|
|
|
|
| |
llvm-svn: 319687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-const data() member of std::string is only exposed
in C++17 and beyond. However std::string is externally instantiated
and so the member function needs to be exposed to be externally instantiated.
On Linux and OS X this shouldn't cause a problem, because
_LIBCPP_INLINE_VISIBILITY ensures the symbol is always inlined.
However on Windows, the symbol gets marked dllimport, but
there is no definition to import, causing link errors.
llvm-svn: 318690
|
|
|
|
|
|
| |
string, string_view, and the free function std::empty(). Removed tabs from <string_view>, which is why the diff is so big.
llvm-svn: 318328
|
|
|
|
|
|
|
|
|
|
| |
Previously this macro used 0/1 to indicate if it was set.
This is unlike all other libc++ configuration macros which
use ifdef/ifndef.
This patch makes this macro consistent with everything else.
llvm-svn: 315995
|
|
|
|
|
|
| |
parameter value for rfind/find_last_of/find_last_not_of
llvm-svn: 312693
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function template is referenced inside class basic_string as a
friend function. The extern template declaration needs to be above that
friend declaration to actually take effect.
This is important because this function was marked as exported in
r307966, so without the extern template taking effect, it can leak into
other DSOs as a visible symbol.
llvm-svn: 309474
|
|
|
|
|
|
|
|
|
| |
Once upon a time, extern templates used to be a Microsoft extension, so
cl would warn about their usage, and libc++ suppressed that warning.
They've long since been standardized, so the warning is defunct. (libc++
also doesn't currently support building with cl anyway.)
llvm-svn: 307997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.
This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.
Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.
llvm-svn: 307966
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using LIBCXX_ABI_UNSTABLE=YES, clang-cl gave the following warning:
P:\llvm_master\src\llvm\projects\libcxx\include\string(683,51):
warning: enumerator value is not representable in the underlying type
'int' [-Wmicrosoft-enum-value]
Fixed by switching from enums to static const size_type.
https://reviews.llvm.org/D35174
llvm-svn: 307751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The string literal operators have implicit instantiations of
basic_string<char> and basic_string<wchar>, which prevent the dllimport
on the subsequent explicit instantiation declarations from having an
effect. Hoisting the explicit instantiations above the implicit ones
fixes the issue.
I think it's pretty unfortunate that the ordering has such an effect,
and I'd fixed the same issue for dllexport in r288682. dllimport is more
complicated from a codegen perspective, however, and clang's behavior of
ignoring the dllimport when there's a previous implicit instantiation is
consistent with cl, so changing the order is our only recourse.
llvm-svn: 306632
|
|
|
|
| |
llvm-svn: 304383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
|
|
|
|
| |
llvm-svn: 300633
|
|
|
|
| |
llvm-svn: 300397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
times, and add constexpr.
Summary:
__compressed_pair takes and passes it's constructor arguments by value. This causes arguments to be moved 3 times instead of once. This patch addresses that issue and fixes `constexpr` on the constructors.
I would rather have this fix than D27564, and I'm fairly confident it's not ABI breaking but I'm not 100% sure.
I prefer this solution because it removes a lot of code and makes the implementation *much* smaller.
Reviewers: mclow.lists, K-ballo
Reviewed By: K-ballo
Subscribers: K-ballo, cfe-commits
Differential Revision: https://reviews.llvm.org/D27565
llvm-svn: 300140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is effectively a partial revert of r278356, which started inlining
basic_string::__init. Even if we want to help the compiler along with
an inlinehint, we shouldn't hamstring it by forcing it to inline all the
time.
Libc++ uses always_inline widely as a limit-the-ABI-hack, but since
__init is already on the dylib boundary, it makes no sense here and just
harms the debugging experience at -O0.
rdar://problem/31013102
llvm-svn: 299290
|
|
|
|
|
|
| |
traits::char_type'. Tests for string_view, too
llvm-svn: 297872
|