summaryrefslogtreecommitdiff
path: root/lld/MachO
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[Demangle] make llvm::demangle take std::string_view rather than ↵Nick Desaulniers2023-05-021-1/+1
| | | | | | | | | | | | | const std::string&" This reverts commit c117c2c8ba4afd45a006043ec6dd858652b2ffcc. itaniumDemangle calls std::strlen with the results of std::string_view::data() which may not be NUL-terminated. This causes lld/test/wasm/why-extract.s to fail when "expensive checks" are enabled via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. See D149675 for further discussion. Back this out until the individual demanglers are converted to use std::string_view.
* [Demangle] make llvm::demangle take std::string_view rather than const ↵Nick Desaulniers2023-05-021-1/+1
| | | | | | | | | | | | | | | | | | std::string& As suggested by @erichkeane in https://reviews.llvm.org/D141451#inline-1429549 There's potential for a lot more cleanups around these APIs. This is just a start. Callers need to be more careful about sub-expressions producing strings that don't outlast the expression using ``llvm::demangle``. Add a release note. Reviewed By: MaskRay, #lld-macho Differential Revision: https://reviews.llvm.org/D149104
* [LTO] Change getThinLTOOutputFile to take StringRefFangrui Song2023-04-261-3/+2
|
* [lld-macho] Tweak the names we give to archive membersJez Ng2023-04-201-3/+2
| | | | | | | | | | | | In particular, make it `foo.a(foo.o)$ARCHIVE_OFFSET`. The goal is to make it more similar to both ld64 implementation, which uses the `foo.a(foo.o)$MODULE_ID` format. We dump some of these names in LTO code, so matching ld64's format is helpful. This format is also more similar to LLD-ELF's, which is `foo.a(foo.o at $ARCHIVE_OFFSET)`. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D148828
* [lld-macho] Add new -reproducible flagKeith Smiley2023-04-062-1/+5
| | | | | | | | | | | | As of Xcode 14.3 it passes -reproducible by default to ld64. It seems this flag was added in ld64 with Xcode 14.0, but it is not documented. Through my testing the only thing I have seen it do is the same as ZERO_AR_DATE, but it's possible it does more, or will do more in the future. Since we already default to this option, this is more about handling the command line flag to maintain Xcode compatibility than anything else. Differential Revision: https://reviews.llvm.org/D147663
* [lld-macho][nfc] std::find_if -> llvm::find_ifJez Ng2023-04-051-4/+2
|
* [lld-macho][nfc] Clean up a bunch of clang-tidy issuesJez Ng2023-04-056-26/+29
|
* [lld] Support separate native object file path in --thinlto-prefix-replaceIvan Tadeu Ferreira Antunes Filho2023-04-043-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the --thinlto-prefix-replace="oldpath;newpath" option is used during distributed ThinLTO thin links to specify the mapping of the input bitcode object files' directory tree (oldpath) to the directory tree (newpath) used for both: 1) the output files of the thin link itself (the .thinlto.bc index files and the optional .imports files) 2) the specified object file paths written to the response file given in the --thinlto-index-only=${response} option, which is used by the final native link and must match the paths of the native object files that will be produced by ThinLTO backend compiles. This patch expands the --thinlto-prefix-replace option to allow a separate directory tree mapping to be specified for the object file paths written to the response file (number 2 above). This is important to support builds and build systems where the same output directory may not be written by multiple build actions (e.g. the thin link and the ThinLTO backend compiles). The new format is: --thinlto-prefix-replace="origpath;outpath[;objpath]" This replaces the origpath directory tree of the thin link input files with outpath when writing the thin link index and imports outputs (number 1 above). If objpath is specified it replaces origpath of the input files with objpath when writing the response file (number 2 above), otherwise it falls back to the old behavior of using outpath for this as well. Reviewed By: tejohnson, MaskRay Differential Revision: https://reviews.llvm.org/D144596
* [lld-macho] Check if DWARF offset is too large for compact unwindJez Ng2023-04-041-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For functions that use DWARF encodings, their compact unwind entry will contain a hint about the offset of their DWARF entry from the start of the `__eh_frame` section. The encoding only has 3 bytes to encode this hint. Previously, I neglected to check for overflow (and didn't realize that the value was merely a hint without needing to be exact.) So for large `__eh_frame` sections, the hint would overflow and cause the compact unwind MODE flag to be corrupted, leading to uncaught exceptions at runtime. This diff fixes things by encoding zero as the hint for offsets that are too large. The unwinder will start a linear search at the hint location for the matching CFI record. The only requirement is that the hint points to a valid CFI record start, and the start of the section is always the start of a CFI record (in well-formed programs). I'm not adding a test for this because generating the test inputs takes a bit too much time. However, I have been testing locally with this lit file, which takes about 15s to run on my machine: ``` # RUN: rm -rf %t; mkdir %t # RUN: llvm-mc -filetype=obj -triple=x86_64-apple-macos11.0 %s -o %t/test.o # RUN: %lld -dylib -lSystem %t/test.o -o %t/test .subsections_via_symbols .text .p2align 2 _f: .cfi_startproc .rept 0x7fffff .cfi_escape 0x2e, 0x10 .endr ret .cfi_endproc _g: .cfi_startproc .cfi_escape 0x2e, 0x10 ret .cfi_endproc ``` Reviewed By: #lld-macho, smeenai Differential Revision: https://reviews.llvm.org/D147505
* [lld-macho] Gate category checking behind --check-category-conflictsJez Ng2023-03-312-1/+5
| | | | | | | | | @oontvoo reports that the current implementation crashes on a bunch of their builds. Let's leave it disabled by default for now. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D147341
* [lld-macho] Don't emit spurious dupe method warnings for +load methodsJez Ng2023-03-301-0/+13
| | | | | | | | | | | | +load methods are static initializers and treated specially by the runtime: all +load methods for a class & its categories are called when loading that class, unlike regular methods where only one definition will get called per message. Thus, there is no need to check for duplicates. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D147230
* [lld-macho][objc] Don't crash when rodata isn't statically linkedJez Ng2023-03-301-6/+8
| | | | | | | | | | | | We were previously assuming that to hold, but it appears that `swiftc` may generate classes that link against `__objc_empty_cache` for their rodata pointer. This should allow us to re-land {D142916} (as a stack). Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D147229
* [lld-macho][re-land] Warn on method name collisions from category definitionsJez Ng2023-03-3010-51/+367
| | | | | | | | | | | | | | | | | | | | | | | | | This implements ld64's checks for duplicate method names in categories & classes. In addition, this sets us up for implementing Obj-C category merging. This diff handles the most of the parsing work; what's left is rewriting those category / class structures. Numbers for chromium_framework: base diff difference (95% CI) sys_time 2.182 ± 0.027 2.200 ± 0.047 [ -0.2% .. +1.8%] user_time 6.451 ± 0.034 6.479 ± 0.062 [ -0.0% .. +0.9%] wall_time 6.841 ± 0.048 6.885 ± 0.105 [ -0.1% .. +1.4%] samples 33 22 Fixes https://github.com/llvm/llvm-project/issues/54912. Issues seen with the previous land will be fixed in the next commit. Reviewed By: #lld-macho, thevinster, oontvoo Differential Revision: https://reviews.llvm.org/D142916
* [lld-macho] Support re-exports of individual symbolsJez Ng2023-03-274-16/+65
| | | | | | | | | | | | Specifically, we support this: ld64.lld -dylib foo.o libbar.dylib -exported_symbol _bar -o libfoo.dylib Where `_bar` is defined in libbar.dylib. Reviewed By: #lld-macho, smeenai Differential Revision: https://reviews.llvm.org/D144153
* [lld-macho] Don't include zero-size private label symbols in map fileJez Ng2023-03-113-9/+10
| | | | | | | | | This is also what ld64 does. This will make it easier to compare their respective map files. Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D145654
* [lld-macho] Print archive names in linker mapJez Ng2023-03-111-4/+15
| | | | | | | | | | | | | If a symbol is pulled in from an archive, we should include the archive name in the map file output. This is what ld64 does. Note that we aren't using `toString(InputFile*)` here because it includes the install name for dylibs in its output, and ld64's map file does not contain those. Reviewed By: #lld-macho, smeenai Differential Revision: https://reviews.llvm.org/D145623
* [lld-macho] Coalesce local symbol aliases along with their aliased weak defJez Ng2023-03-112-25/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This supersedes {D139069}. In some ways we are now closer to ld64's behavior: we previously only did this coalescing for private-label symbols, but now we do it for all locals, just like ld64. However, we no longer generate weak binds when a local alias to a weak symbol is referenced. This is merely for implementation simplicity; it's not clear to me that any real-world programs depend on us emulating this behavior. The problem with the previous approach is that we ended up with duplicate references to the same symbol instance in our InputFiles, which translated into duplicate symbols in our output. While we could work around that problem by performing a dedup step before emitting the symbol table, it seems cleaner to not generate duplicate references in the first place. Numbers for chromium_framework on my 16 Core Intel Mac Pro: base diff difference (95% CI) sys_time 2.243 ± 0.093 2.231 ± 0.066 [ -2.5% .. +1.4%] user_time 6.529 ± 0.087 6.080 ± 0.050 [ -7.5% .. -6.3%] wall_time 6.928 ± 0.175 6.474 ± 0.112 [ -7.7% .. -5.4%] samples 26 31 Yep, that's a massive win... because it turns out that {D140606} and {D139069} caused a regression (of about the same size.) I just didn't think to measure them back then. I'm guessing all the extra symbols we have been emitting did not help perf at all... Reviewed By: lgrey Differential Revision: https://reviews.llvm.org/D145455
* Revert "[lld-macho] Warn on method name collisions from category definitions"Jez Ng2023-03-0810-366/+51
| | | | | | | This reverts commit ef122753db7fe8e9a0b7bedd46d2f3668a780fcb. Apparently it is causing some crashes: https://reviews.llvm.org/D142916#4178869
* [lld-macho][nfc] Convert more alignTo() to alignToPowerOf2()Jez Ng2023-03-073-14/+17
| | | | | | Reviewed By: #lld-macho, smeenai Differential Revision: https://reviews.llvm.org/D145261
* [lld-macho] Warn on method name collisions from category definitionsJez Ng2023-03-0710-51/+366
| | | | | | | | | | | | | | | | | | | | | | | This implements ld64's checks for duplicate method names in categories & classes. In addition, this sets us up for implementing Obj-C category merging. This diff handles the most of the parsing work; what's left is rewriting those category / class structures. Numbers for chromium_framework: base diff difference (95% CI) sys_time 2.182 ± 0.027 2.200 ± 0.047 [ -0.2% .. +1.8%] user_time 6.451 ± 0.034 6.479 ± 0.062 [ -0.0% .. +0.9%] wall_time 6.841 ± 0.048 6.885 ± 0.105 [ -0.1% .. +1.4%] samples 33 22 Fixes https://github.com/llvm/llvm-project/issues/54912. Reviewed By: #lld-macho, thevinster, oontvoo Differential Revision: https://reviews.llvm.org/D142916
* [lld-macho] Avoid running LTO pipeline for no filesKeith Smiley2023-03-032-6/+9
| | | | | | | | | | | If no bitcode files are given as inputs but -object_path_lto is passed we should avoid running the LTO pipeline. This mirrors this patch from the ELF port https://github.com/llvm/llvm-project/commit/f3994e4dfa0214b2a09a0e327ba37e6b38bbcdb3 Fixes https://github.com/llvm/llvm-project/issues/61031 Differential Revision: https://reviews.llvm.org/D145273
* [lld-macho] Remove duplicate minimum version infoKeith Smiley2023-03-035-41/+40
| | | | | | | | | | At some point PlatformInfo's Target changed types to a type that also has minimum deployment target info. This caused ambiguity if you tried to get the target triple from the Target, as the actual minimum version info was being stored separately. This bulk of this change is changing the parsing of these values to support this. Differential Revision: https://reviews.llvm.org/D145263
* [lld-macho] Ignore -debug_variant flagKeith Smiley2023-03-031-4/+4
| | | | | | | | | As far as I can tell all this flag does in ld64 is warn about cases where you're building dylibs that are going to be part of the shared cache, which I assume only apple is doing. Strangely I have seen this flag being passed in the wild so this silences the warning about it. Differential Revision: https://reviews.llvm.org/D145200
* [lld-macho] Use uint64_t instead of size_t to fix 32 bit test failuresDavid Spickett2023-02-161-1/+1
| | | | | | | | | | | Our bot has been failing https://lab.llvm.org/buildbot/#/builders/178/builds/3967: Assertion `isecEnd - isecVA <= forwardBranchRange && "should only finalize sections in jump range"' failed. I think this is due to the use of size_t, which is 32 bit on 32 bit, for a value used in some 64 bit address calculations. Which was added in https://reviews.llvm.org/D144029. Switching to uint64_t fixes the issues.
* [LLD] Add --lto-CGO[0-3] optionScott Linder2023-02-154-4/+21
| | | | | | | | | | | | | | | | | | Allow controlling the CodeGenOpt::Level independent of the LTO optimization level in LLD via new options for the COFF, ELF, MachO, and wasm frontends to lld. Most are spelled as --lto-CGO[0-3], but COFF is spelled as -opt:lldltocgo=[0-3]. See D57422 for discussion surrounding the issue of how to set the CG opt level. The ultimate goal is to let each function control its CG opt level, but until then the current default means it is impossible to specify a CG opt level lower than 2 while using LTO. This option gives the user a means to control it for as long as it is not handled on a per-function basis. Reviewed By: MaskRay, #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D141970
* [lld-macho] Account for alignment in thunk insertion algorithmJez Ng2023-02-141-3/+7
| | | | | | | | | | | | | | | We previously neglected this, leading us to underestimate the maximum possible branch address offset. Fixing this should allow us to reduce `slop` to more reasonable levels. I've lowered it to 256 for now, though I suspect we could go lower. Fixes https://github.com/llvm/llvm-project/issues/59259. Reviewed By: serge-sans-paille Differential Revision: https://reviews.llvm.org/D144029
* [NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott2023-02-101-1/+1
| | | | | | | The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
* Use llvm::count{lr}_{zero,one} (NFC)Kazu Hirata2023-01-282-3/+3
|
* [NFC] Optimize vector usage in lldJez Ng2023-01-262-10/+10
| | | | | | | | | | By using emplace_back, as well as converting some loops to for-each, we can do more efficient vectorization. Make copy constructor for TemporaryFile noexcept. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D139552
* [lld] Remove transitional legacy pass manager flagsArthur Eubanks2023-01-261-3/+0
| | | | | | Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D142571
* [lld-macho] Have all load commands aligned to the word sizeJez Ng2023-01-241-2/+4
| | | | | | | | This is what ld64 does, and also what we already do for most of the other load commands. I'm not aware of a good way to test this, but I don't think it really matters. Differential Revision: https://reviews.llvm.org/D141462
* [lld-macho] Improve invalid fat binary warningKeith Smiley2023-01-141-2/+10
| | | | | | | | This nearly mirrors ld64's error for this case: ld: warning: ignoring file path/to/file, file is universal (armv7,arm64) but does not contain the x86_64 architecture: path/to/file Differential Revision: https://reviews.llvm.org/D141729
* Remove redundant initialization of std::optional (NFC)Kazu Hirata2023-01-141-1/+1
|
* [lld][Mach-O] Fix build with Mach-O due to missing libraryJoseph Huber2023-01-131-0/+1
| | | | | | Summary: The build was failing due to an undefined symbol. This is because this function is defined in the `BitWriter` component but was not linked.
* [lld/mac] Add support for distributed ThinLTONico Weber2023-01-127-12/+194
| | | | | | | | | | | | | | | | | | | | | | | Adds support for the following flags: * --thinlto-index-only, --thinlto-index-only= * --thinlto-emit-imports-files * --thinlto-emit-index-files * --thinlto-object-suffix-replace= * --thinlto-prefix-replace= See https://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html for some words on --thinlto-index-only. I don't really need the other flags, but they were in the vicinity and _someone_ might need them, so I figured I'd add them too. `-object_path_lto` now sets `c.AlwaysEmitRegularLTOObj` as in the other ports, which means it can now only point to a filename for non-thin LTO. I think that was the intent of D129705 anyways, so update test/MachO/lto-object-path.ll to use a non-thin bitcode file for that test. Differential Revision: https://reviews.llvm.org/D138451
* [lld-macho] Downgrade missing fat arch to warningKeith Smiley2023-01-121-1/+1
| | | | | | | | | | | This mirrors ld64's behavior. In many cases this likely still leads to a link failure but if you didn't actually use anything from the library it can be ignored. If you care about these invalid cases -fatal_warnings still upgrades it back to an error. Example: https://github.com/keith/ld64.lld/issues/3 Differential Revision: https://reviews.llvm.org/D141638
* [OptTable] Precompute OptTable prefixes union table through tablegenserge-sans-paille2023-01-122-2/+2
| | | | | | | | | | | | | | This avoid rediscovering this table when reading each options, providing a sensible 2% speedup when processing and empty file, and a measurable speedup on typical workloads, see: This is optional, the legacy, on-the-fly, approach can still be used through the GenericOptTable class, while the new one is used through PrecomputedOptTable. https://llvm-compile-time-tracker.com/compare.php?from=4da6cb3202817ee2897d6b690e4af950459caea4&to=19a492b704e8f5c1dea120b9c0d3859bd78796be&stat=instructions:u Differential Revision: https://reviews.llvm.org/D140800
* [lld-macho][nfc] Use alignToPowerOf2 instead of alignTo when possibleJez Ng2023-01-111-7/+8
| | | | | | | | | | Skips the divide operation which is generally expensive. Not that it matters in this diff, the code changed is not particularly hot, but just for principle & consistency... Reviewed By: #lld-macho, oontvoo, MaskRay Differential Revision: https://reviews.llvm.org/D141461
* [lld-macho] Prevent assertions for aliases to weak_def_can_be_hidden symbolsPaul Kirth2023-01-091-2/+0
| | | | | | | | | | | | | | | | | In https://reviews.llvm.org/D137982 we found that on Mach-O private aliases could trigger an assert in lld when the aliasee was a weak_def_can_be_hidden symbol. This appears to be incorrect, and should be allowed in Mach-O. Disallowing this behavior is also inconsistent with how ld64 handles a private alias to weak_def_can_be_hidden symbols. This patch removes the assert and tests that LLD handles such aliases gracefully. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D141082
* [lld-macho] Don't support relocations in cstring sectionsJez Ng2023-01-051-12/+9
| | | | | | | | | | | | | | | We can technically handle them, but since they shouldn't come up in any real-world programs (since ld64 dedups strings unconditionally), there's no reason to support them. It's a thoroughly untested code path too -- as evidenced by the fact that the only test this change breaks is one that verifies that we reject relocations when dedup'ing. There is no test that covers the case where we handle relocations in cstring sections when dedup is disabled. Reviewed By: #lld-macho, oontvoo, keith, thakis Differential Revision: https://reviews.llvm.org/D141025
* [lld] Fix iwyu problems after 83d59e05b201760e3f364ff6316301d347cbad95Fangrui Song2022-12-281-0/+1
| | | | | The commit transitively includes lld/include/lld/Common/ErrorHandler.h into lld/include/lld/Common/Driver.h, which is not intended.
* [clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille2022-12-271-1/+4
| | | | | | | | | | | | | | | | | call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470. The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e. The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable. Differential Revision: https://reviews.llvm.org/D139881
* Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵Vitaly Buka2022-12-251-4/+1
| | | | | | | | | | | | | | | | builtin and call information" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4" GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104 compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0. This reverts commit caa713559bd38f337d7d35de35686775e8fb5175. This reverts commit 06b90e2e9c991e211fecc97948e533320a825470. This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
* [clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille2022-12-241-1/+4
| | | | | | | | | | | | | | | | | | | | | call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 that into account a GGC issue (probably https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181) when dealing with intiailizer_list and constant expressions. Workaround this by avoiding initializer list, at the expense of a temporary plain old array. Differential Revision: https://reviews.llvm.org/D139881
* [lld-macho] Standardize error messagesJez Ng2022-12-233-12/+19
| | | | | | | | | Errors / warnings that originate from a particular file should be of the form `$file: $message`. Reviewed By: #lld-macho, keith Differential Revision: https://reviews.llvm.org/D140634
* [lld-macho] Only fold private-label aliases that do not have flagsJez Ng2022-12-231-9/+16
| | | | | | | | | | | | | | | | | | | | This will enable us to re-land {D139069}. The issue with the original diff was that we were folding all private-label symbols. We were not merging the symbol flags during this folding; instead we just made all references to the folded symbol point to its aliasee. This caused some flags to be incorrectly discarded. This surfaced as code that was incorrectly stripped due to LLD dropping the `.no_dead_strip` flag. This diff fixes things by only folding flag-less private-label aliases. Most (maybe all) of the `ltmp<N>` symbols that are generated by the MC aarch64 backend are flag-less, so this conservative folding behavior does the job. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D140606
* [reland][lld-macho] Private label aliases to weak symbols should not retain ↵Jez Ng2022-12-232-6/+26
| | | | | | | | section data This reverts commit a650f2ec7a37cf1f495108bbb313e948c232c29c. The crashes it was causing will be fixed by the stacked diff {D140606}.
* Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵serge-sans-paille2022-12-231-3/+2
| | | | | | | | | | builtin and call information" There are still remaining issues with GCC 12, see for instance https://lab.llvm.org/buildbot/#/builders/93/builds/12669 This reverts commit 5ce4e92264102de21760c94db9166afe8f71fcf6.
* [clang] Use a StringRef instead of a raw char pointer to store builtin and ↵serge-sans-paille2022-12-231-2/+3
| | | | | | | | | | | | | | | | | call information This avoids recomputing string length that is already known at compile time. It has a slight impact on preprocessing / compile time, see https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 with a change to llvm/utils/TableGen/OptParserEmitter.cpp to cope with GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Differential Revision: https://reviews.llvm.org/D139881
* Revert "[clang] Use a StringRef instead of a raw char pointer to store ↵serge-sans-paille2022-12-231-3/+2
| | | | | | | | | builtin and call information" Failing builds: https://lab.llvm.org/buildbot#builders/9/builds/19030 This is GCC specific and has been reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 This reverts commit 719d98dfa841c522d8d452f0685e503538415a53.
View Lorry Controller Status