| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
[lib++][Format] Updates Unicode database. (#125712) Updates the databease to the Unicode release 16.0.0. The algorithms of the Grapheme clustering rules have not changed. | 1 年前 | |
[libc++] Avoid type-punning between __hash_value_type and pair (#143501) This patch is very similar to #134819 in nature. Before this patch, we were dereferencing pointers to objects which were never constructed. Now we always assume that nodes store pair<const KeyT, ValueT> for unordered_maps instead, as they actually do. | 1 年前 | |
[NFC] [test] [libcxx] Fix invalid escape sequences (#168636) >>> "_target-has-llvm-21 || target={{.+}}-apple-macosx{{26.[0-9](.\d+)?}}" == r"_target-has-llvm-21 || target={{.+}}-apple-macosx{{26.[0-9](.\\ d+)?}}" <python-input-6>:1: SyntaxWarning: invalid escape sequence '\d' True >>> "_target-has-llvm-20 || target={{.+}}-apple-macosx{{15.[4-9](.\d+)?}}" == r"_target-has-llvm-20 || target={{.+}}-apple-macosx{{15.[4-9](.\\ d+)?}}" <python-input-7>:1: SyntaxWarning: invalid escape sequence '\d' True >>> "_target-has-llvm-19 || target={{.+}}-apple-macosx{{15.[0-3](.\d+)?}}" == r"_target-has-llvm-19 || target={{.+}}-apple-macosx{{15.[0-3](.\\ d+)?}}" <python-input-8>:1: SyntaxWarning: invalid escape sequence '\d' True >>> "_target-has-llvm-18 || target={{.+}}-apple-macosx{{14.[4-9](.\d+)?}}" == r"_target-has-llvm-18 || target={{.+}}-apple-macosx{{14.[4-9](.\\ d+)?}}" <python-input-9>:1: SyntaxWarning: invalid escape sequence '\d' True | 8 个月前 | |
Start libc++ python cleanup and consolidation. Libc++ frequently creates and uses utilities written in python. Currently there are python modules under both libcxx/test and libcxx/util. My goal with these changes is to consolidate them into a single package under libcxx/utils/libcxx. llvm-svn: 294644 | 9 年前 | |
[libc++][modules] Rewrite the modulemap to have fewer top-level modules (#110501) This is a re-application of bc6bd3bc1e9 which was reverted in f11abac6524 because it broke the Clang pre-commit CI. Original commit message: This patch rewrites the modulemap to have fewer top-level modules. Previously, our modulemap had one top level module for each header in the library, including private headers. This had the well-known problem of making compilation times terrible, in addition to being somewhat against the design principles of Clang modules. This patch provides almost an order of magnitude compilation time improvement when building modularized code (certainly subject to variations). For example, including <ccomplex> without a module cache went from 22.4 seconds to 1.6 seconds, a 14x improvement. To achieve this, one might be tempted to simply put all the headers in a single top-level module. Unfortunately, this doesn't work because libc++ provides C compatibility headers (e.g. stdlib.h) which create cycles when the C Standard Library headers are modularized too. This is especially tricky since base systems are usually not modularized: as far as I know, only Xcode 16 beta contains a modularized SDK that makes this issue visible. To understand it, imagine we have the following setup: // in libc++'s include/c++/v1/module.modulemap module std { header stddef.h header stdlib.h } // in the C library's include/module.modulemap module clib { header stddef.h header stdlib.h } Now, imagine that the C library's <stdlib.h> includes <stddef.h>, perhaps as an implementation detail. When building the std module, libc++'s <stdlib.h> header does #include_next <stdlib.h> to get the C library's <stdlib.h>, so libc++ depends on the clib module. However, remember that the C library's <stdlib.h> header includes <stddef.h> as an implementation detail. Since the header search paths for libc++ are (and must be) before the search paths for the C library, the C library ends up including libc++'s <stddef.h>, which means it depends on the std module. That's a cycle. To solve this issue, this patch creates one top-level module for each C compatibility header. The rest of the libc++ headers are located in a single top-level std module, with two main exceptions. First, the module containing configuration headers (e.g. <__config>) has its own top-level module too, because those headers are included by the C compatibility headers. Second, we create a top-level std_core module that contains several dependency-free utilities used (directly or indirectly) from the __math subdirectory. This is needed because __math pulls in a bunch of stuff, and __math is used from the C compatibility header <math.h>. As a direct benefit of this change, we don't need to generate an artificial __std_clang_module header anymore to provide a monolithic std module, since our modulemap does it naturally by construction. A next step after this change would be to look into whether math.h really needs to include the contents of __math, and if so, whether libc++'s math.h truly needs to include the C library's math.h header. Removing either dependency would break this annoying cycle. Thanks to Eric Fiselier for pointing out this approach during a recent meeting. This wasn't viable before some recent refactoring, but wrapping everything (except the C headers) in a large module is by far the simplest and the most effective way of doing this. Fixes #86193 | 1 年前 | |
[libc++][NFC] Use consistent layout for license in Python files Most Python files were using # === [...] instead of #=== [...] so I went with what was the most common in the codebase. | 1 年前 | |
[libc++] Fix bug with appending and overwriting in benchmark-historical The logic was wrong when the data file did not already exist but we were in 'append' mode. | 10 个月前 | |
[libc++] Add scripts to build and test libc++ at a specified commit (#158104) This is useful to perform historical analyses, bisections or establish a benchmarking baseline after making some changes on a branch. For example, one can run benchmarks against main and easily compare them to the results on the current feature branch with: libcxx/utils/test-at-commit --commit $(git merge-base main HEAD) \ -B build/baseline -- <lit args> libcxx/utils/libcxx-lit build/candidate <lit args> libcxx/utils/compare-benchmarks \ <(libcxx/utils/consolidate-benchmarks build/baseline) \ <(libcxx/utils/consolidate-benchmarks build/candidate) Doing this without these scripts would require checking out the desired baseline, setting up the build directory and running the tests manually. With these scripts, this can automatically be automated without dirtying the current checkout. | 10 个月前 | |
[libc++] Add a merge driver that can apply clang-format (#73712) In preparation for the moment when we'll clang-format the whole code base, this patch adds a script that can be used to rebase patches across clang-format changes mechanically, without requiring manual intervention. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all. | 2 年前 | |
[libc++] Fix off-by-one error in compare-benchmarks script That led us to overwrite the data of the last row with the geomean. | 9 个月前 | |
[libc++] Update utilities to compare benchmarks (#157556) This patch replaces the previous libcxx-compare-benchmarks wrapper by a new compare-benchmarks script which works with LNT-compatible data. This allows comparing benchmark results across libc++ microbenchmarks, SPEC, and anything else that would produce LNT-compatible data. It also adds a simple script to consolidate LNT benchmark output into a single file, simplifying the process of doing A/B runs locally. The simplest way to do this doesn't require creating two build directories after this patch anymore. It also adds the ability to produce either a standalone HTML chart or a plain text output for diffing results locally when prototyping changes. Example text output of the new tool: Benchmark Baseline Candidate Difference % Difference ----------------------------------- ---------- ----------- ------------ -------------- BM_join_view_deques/0 8.11 8.16 0.05 0.63 BM_join_view_deques/1 13.56 13.79 0.23 1.69 BM_join_view_deques/1024 6606.51 7011.34 404.83 6.13 BM_join_view_deques/2 17.99 19.92 1.93 10.72 BM_join_view_deques/4000 27655.58 29864.72 2209.14 7.99 BM_join_view_deques/4096 26218.07 30520.13 4302.05 16.41 BM_join_view_deques/512 3231.66 2832.47 -399.19 -12.35 BM_join_view_deques/5500 47144.82 42207.41 -4937.42 -10.47 BM_join_view_deques/64 247.23 262.66 15.43 6.24 BM_join_view_deques/64000 756221.63 511247.48 -244974.15 -32.39 BM_join_view_deques/65536 537110.91 560241.61 23130.70 4.31 BM_join_view_deques/70000 815739.07 616181.34 -199557.73 -24.46 BM_join_view_out_vectors/0 0.93 0.93 0.00 0.07 BM_join_view_out_vectors/1 3.11 3.14 0.03 0.82 BM_join_view_out_vectors/1024 3090.92 3563.29 472.37 15.28 BM_join_view_out_vectors/2 5.52 5.56 0.04 0.64 BM_join_view_out_vectors/4000 9887.21 9774.40 -112.82 -1.14 BM_join_view_out_vectors/4096 10158.78 10190.44 31.66 0.31 BM_join_view_out_vectors/512 1218.68 1209.59 -9.09 -0.75 BM_join_view_out_vectors/5500 13559.23 13676.06 116.84 0.86 BM_join_view_out_vectors/64 158.95 157.91 -1.04 -0.65 BM_join_view_out_vectors/64000 178514.73 226520.97 48006.24 26.89 BM_join_view_out_vectors/65536 184639.37 207180.35 22540.98 12.21 BM_join_view_out_vectors/70000 235006.69 213886.93 -21119.77 -8.99 | 10 个月前 | |
[libc++] Add a script to find outliers and re-run candidates in LNT results This allows selectively re-running benchmarks that are suspected to contain a lot of noise. | 9 个月前 | |
[NFC][Py Reformat] Reformat python files in libcxx/libcxxabi This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Reviewed By: #libc, kwk, Mordante Differential Revision: https://reviews.llvm.org/D150763 | 3 年前 | |
[libc++] Granularize <cstddef> includes (#108696) | 1 年前 | |
[libc++] Granularize <cstddef> includes (#108696) | 1 年前 | |
[libc++] Remove unused Python imports (#73724) VSCode's Pylance extension informed me, and text searching confirmed, that these imports are unused. I believe we should be able to remove them harmlessly. | 2 年前 | |
[libc++] Implement P2988R12: std::optional<T&> (#155202) Resolves #148131 - Unlock std::optional<T&> implementation - Allow instantiations of optional<T(&)(...)> and optional<T(&)[]> but disables value_or() and optional::iterator + all iterator related functions - Update documentation - Update tests | 8 个月前 | |
[libc++] Granularize <cstddef> includes (#108696) | 1 年前 | |
Reapply "[libc++][C++03] Copy the LLVM 19 headers (#108999)" (#112127) This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387. This disables the IWYU mapping that caused the failure, since the headers aren't reachable for now. This is the first part of the "Freezing C++03 headers" proposal explained in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319/58. This patch mechanically copies the headers as of the LLVM 19.1 release into a subdirectory of libc++ so that we can start using these headers when building in C++03 mode. We are going to be backporting important changes to that copy of the headers until the LLVM 21 release. After the LLVM 21 release, only critical bugfixes will be fixed in the C++03 copy of the headers. This patch only performs a copy of the headers -- these headers are still unused by the rest of the codebase. | 1 年前 | |
[libc++] Fix missing encoding in open() call in python script (#154594) This is a simple fix for the script not being able to run on some platforms due to a missing encoding parameter. Co-authored-by: siradam7th <siradam7th@users.noreply.github.com> | 10 个月前 | |
[libc++] Granularize <cstddef> includes (#108696) | 1 年前 | |
[libc++][NFC] Tabs to space in libcxx-lit script | 2 年前 | |
[libc++] Escape spaces in GoogleBenchmark microbenchmarks Otherwise we generate data that isn't valid according to the LNT format. | 10 个月前 | |
[libc++] Improve handling of runtime errors inside SPEC benchmarks Previously, we would report a successful run if the benchmark exited with an error, and we would produce a timing for the benchmark. After this patch, we consider an error in the benchmark to be a failed LIT test and we don't produce any benchmark data for it. | 10 个月前 | |
[libcxx] Require qemu-system-arm for armv7m builder (#77067) And add a check in the python script that the binary given to --qemu actually exists. Otherwise you get a generic Python error: `` # .---command stderr------------ # | Traceback (most recent call last): # | File "/home/david.spickett/modules-llvm-project/libcxx/utils/qemu_baremetal.py", line 70, in <module> # | exit(main()) # | File "/home/david.spickett/modules-llvm-project/libcxx/utils/qemu_baremetal.py", line 66, in main # | os.execvp(qemu_commandline[0], qemu_commandline) # | File "/usr/lib/python3.8/os.py", line 568, in execvp # | _execvpe(file, args) # | File "/usr/lib/python3.8/os.py", line 610, in _execvpe # | raise last_exc # | File "/usr/lib/python3.8/os.py", line 601, in _execvpe # | exec_func(fullname, *argrest) # | FileNotFoundError: [Errno 2] No such file or directory # ----------------------------- # error: command failed with exit status: 1 ``` When it tries to run the entire command later. For the builder, it's only ever going to use qemu-system-arm so error at config time if it's not there. | 2 年前 | |
[libc++] Improve historical benchmark visualization - Use LOWESS instead of OLS trendlines, it tends to fit data better - Plot using the commit date instead of the arbitrary revlist order - Fix progress bar reporting when we prefetch Git commit data - Allow adding a subtitle to charts, which is helpful to stay organized - Ensure that series are always presented in the same (alphabetical) order | 10 个月前 | |
[libc++] Fix how we run codesign in the test suite when --codesign_identity is provided | 2 年前 | |
| 9 个月前 | ||
[libc++] Reject abilist if it contains an ABI tag (#139030) We currently don't have any ABI tags in our dylib symbols, and this is unlikely to change in the future. By diagnosing this we avoid accidentally adding one through e.g. having _LIBCPP_HIDE_FROM_ABI on an exported symbol. | 1 年前 | |
[libc++] Start tracking Github issues in status pages (#149833) This patch adds another row to the Status pages that cross-references the Github issue. It also ensures that the synchronization script takes that new row into account. This should make it easier to find out about the detailed status of a paper from the status pages by clicking on the link and being taken directly to its associated Github issue. I expect that this should remove the need for many "Notes" which simply duplicate the information of which parts of a paper are implemented: instead we can list that the implementation is partial and users can click on the Github issue to see what's implemented. | 10 个月前 | |
[libc++] Fix a few incorrect find-and-replace in the %{temp} change | 9 个月前 | |
[libc++] Allow customizing trendline in visualize-historical script | 9 个月前 | |
[SystemZ][z/OS] Add ASCII and 32-bit variants for libc++. This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces: # ASCII version of libc++ named as libc++_a.so # Script to rename DLL name inside the generated side deck # Various names for dataset members where DLL libraries and their side decks will reside # Add the following options: - LIBCXX_SHARED_OUTPUT_NAME - LIBCXX_ADDITIONAL_COMPILE_FLAGS - LIBCXX_ADDITIONAL_LIBRARIES - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS - LIBCXXABI_ADDITIONAL_LIBRARIES **Background and rational of this patch** The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name. If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL. Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D118503 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 9 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 3 年前 |