[clang][driver][clang-cl] Fix unused argument warning for /std:c++20 for precompiled module inputs to clang-cl
#102435
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…lvm#101884) It is unused by subsequent memcpy.
The tests kept being based on std::string instead of std::string_view to allow testing with older C++ dialects. Adds tests for: - LWG3112 system_error and filesystem_error constructors taking a string may not be able to meet their postconditions
Now that llvm#98275 has been merged, the footnote for P0645 has become outdated. This updates the status information.
This is a preparation for changing the data structure of MBBMap.
For invariant stores to an address of a reduction, only the latest store will be generated outside the loop. Consider earlier stores as dead. This fixes a difference between the legacy and VPlan-based cost model. Fixes llvm#96294.
…m#101828) For functions with private linkage, pick IMAGE_SYM_CLASS_STATIC rather than IMAGE_SYM_CLASS_EXTERNAL; GlobalValue::isInternalLinkage() only checks for InternalLinkage, while GlobalValue::isLocalLinkage() checks for both InternalLinkage and PrivateLinkage. This matches what the AArch64 target does, since commit 3406934. This activates a preexisting fix for the AArch64 target from 1e7f592, for the ARM target as well. When a relocation points at a symbol, one usually can convey an offset to the symbol by encoding it as an immediate in the instruction. However, for the ARM and AArch64 branch instructions, the immediate stored in the instruction is ignored by MS link.exe (and lld-link matches this aspect). (It would be simple to extend lld-link to support it - but such object files would be incompatible with MS link.exe.) This was worked around by 1e7f592 by emitting symbols into the object file symbol table, for temporary symbols that otherwise would have been omitted, if they have the class IMAGE_SYM_CLASS_STATIC, in order to avoid needing an offset in the relocated instruction. This change gives the symbols generated from functions with the IR level "private" linkage the right class, to activate that workaround. This fixes llvm#100101, fixing code generation for coroutines for Windows on ARM. After the change in f786881, coroutines generate a function with private linkage, and calls to this function were previously broken for this target.
getValue returns a const APInt &. So using a const APInt & will avoid a copy.
…ontext (llvm#101745) Prior to this patch, during constraint normalization we could forget from which declaration an atomic constraint was normalized from. Subsequently when performing parameter mapping substitution for that atomic constraint with an incorrect context, we couldn't correctly recognize which declarations are supposed to be visible. Fixes llvm#60336
…1594) This is mostly a cleanups patch, with some hard to observe sugar preservation improvements. Except for the function template deduction changes which improve some pre-existing diagnostics a little bit.
We use armv8m.main-none-eabi now, not armv8m.main-unknown-eabi.
This makes use of the changes introduced in D134604, in order to instantiate alias templates witn a final sugared substitution. This comes at no additional relevant cost. Since we don't track / unique them in specializations, we wouldn't be able to resugar them later anyway. Differential Revision: https://reviews.llvm.org/D136565
…nsn (llvm#101428) Peilen Ye reported an issue ([1]) where for __sync_fetch_and_add(...) without return value like __sync_fetch_and_add(&foo, 1); llvm BPF backend generates locked insn e.g. lock *(u32 *)(r1 + 0) += r2 If __sync_fetch_and_add(...) returns a value like res = __sync_fetch_and_add(&foo, 1); llvm BPF backend generates like r2 = atomic_fetch_add((u32 *)(r1 + 0), r2) The above generation of 'lock *(u32 *)(r1 + 0) += r2' caused a problem in jit since proper barrier is not inserted. The above discrepancy is due to commit [2] where it tries to maintain backward compatability since before commit [2], __sync_fetch_and_add(...) generates lock insn in BPF backend. Based on discussion in [1], now it is time to fix the above discrepancy so we can have proper barrier support in jit. This patch made sure that __sync_fetch_and_add(...) always generates atomic_fetch_add(...) insns. Now 'lock *(u32 *)(r1 + 0) += r2' can only be generated by inline asm. I also removed the whole BPFMIChecking.cpp file whose original purpose is to detect and issue errors if XADD{W,D,W32} may return a value used subsequently. Since insns XADD{W,D,W32} are all inline asm only now, such error detection is not needed. [1] https://lore.kernel.org/bpf/[email protected]/T/#mb68d67bc8f39e35a0c3db52468b9de59b79f021f [2] llvm@286daaf Co-authored-by: Yonghong Song <[email protected]>
As noted in https://github.com/llvm/llvm-project/pull/100367/files#r1695442138, RISCVMaskedPseudoInfo currently stores two things, whether or not a masked pseudo has an unmasked variant, and whether or not it's element-wise. These are separate things, so this patch splits the latter out into the underlying instruction's TSFlags to help make the semantics of llvm#100367 more clear. To the best of my knowledge the only non-element-wise instructions in V are: - vredsum.vs and other reductions - vcompress.vm - vms*f.m - vcpop.m and vfirst.m - viota.m In vector crypto the instructions that operate on element groups are conservatively marked (this might be fine to relax later given since non-EGS multiple vls are reserved), as well as the SiFive extensions and XTHeadVdot.
Avoid redundant dyn_cast to instruction before chain of dyn_cast to specific instructions.
…lvm#101868) If c1 is a mask with c3 leading zeros and c3 is larger than c2. Fixes regression reported in llvm#101751.
The current interpreter emits the diagnostic and continues, so do the same.
…llvm#101625) We don't really care about the precise label values for specific tests like this, so just match any number. The comments are enough to say where we jump in every case, and we have plenty of tests that check basic match table features (on top of being just tested by the fact GlobalISel CodeGen isn't broken).
Currently, the only way to see the passes that were registered is by calling “mlir-opt --help”. However, for compilers with 500+ passes, the help message becomes too long and sometimes hard to understand. In this PR I add a new "--list-passes" option to mlir-opt, which can be used for printing only the registered passes, a feature that would be extremely useful.
Summary: The intention behind this code was to null terminate the `envp` string, but it accidentally went into the string data.
…ing with stripped binaries (llvm#99362) @walter-erquinigo found the the [PR with testing and a fix for DebugInfoD](llvm#98344) caused an issue when working with stripped binaries. The issue is that when you're working with split-dwarf, there are *3* possible files: The stripped binary the user is debugging, the "only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The debuginfod plugin should provide the unstripped/OKD binary. However, if the debuginfod plugin fails, the default symbol locator plugin will just return the stripped binary, which doesn't help. So, to address that, the SymbolVendorELF code checks to see if the SymbolLocator's ExecutableObjectFile request returned the same file, and bails if that's the case. You can see the specific diff as the second commit in the PR. I'm investigating adding a test: I can't quite get a simple repro, and I'm unwilling to make any additional changes to Makefile.rules to this diff, for Pavlovian reasons.
This patch adds entry point in the runtime to be able to allocate descriptors in managed memory. These entry points currently only call `CUFAllocManaged` and `CUFFreeManaged` but could be more complicated in the future. `cuf.alloc` and `cuf.free` related to local descriptors are converted into runtime calls.
This patch implements sandboxir::AllocaInst which mirrors llvm::AllocaInst.
- After ExpandVP pass is merged into PreISelIntrinsicLowering
sharadhr
requested review from
cyndyishida,
aaupov,
maksfb,
rafaelauler,
ayermolo,
dcci,
JDevlieghere,
tbaederr,
Endilll and
a team
as code owners
|
This is not good. You should checkout the branch from the current release/19.x branch and cherry-pick your commit to that branch and create a PR for it. Let's make it in another PR |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Manual backport PR for #99300.