-
Notifications
You must be signed in to change notification settings - Fork 12.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getStyleDiagHandler #91314
getStyleDiagHandler #91314
Conversation
…79641) Currently, the way that recomputeLiveIns works is that it will recompute the livein registers for that MachineBasicBlock but it matters what order you call recomputeLiveIn which can result in incorrect register allocations down the line. Now we do not recompute the entire CFG but we do ensure that the newly added MBB do reach convergence. This fixes a register allocation bug introduced in AArch64 stack probing. (cherry picked from commit ff4636a)
… to 8 (llvm#68925) (llvm#79480) This change saves memory by providing the allocator more freedom to allocate the most efficient size class by dropping the alignment requirements for std::string's pointer from 16 to 8. This changes the output of std::string::max_size, which makes it ABI breaking. That said, the discussion concluded that we don't care about this ABI break. and would like this change enabled universally. The ABI break isn't one of layout or "class size", but rather the value of "max_size()" changes, which in turn changes whether `std::bad_alloc` or `std::length_error` is thrown for large allocations. This change is the child of PR llvm#68807, which enabled the change behind an ABI flag.
… of the same type) (llvm#77768)" in release/18.x (llvm#79400) - Revert "[SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (llvm#77768)", see llvm#77768 (comment)
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
…lvm#80152) Documents support for Load-Acquire RCpc instructions v3 (rcpc3) as well as Memory Copy and Memory Set Acceleration instructions (mops) when targeting AArch64.
…79549) Fixes llvm#78965. (cherry picked from commit f826f55)
Close llvm#79240. See the linked issue for details. Given the frequency of issue reporting about false positive ODR checks (I received private issue reports too), I'd like to backport this to 18.x too.
Previosly we land llvm@085eae6 to workaround the false positive ODR violations in llvm#76638. However, we decided to not perform ODR checks for decls from GMF in llvm#79240 and we land the corresponding change. So we should be able to remove the workaround now. The original tests get remained.
Close llvm#79240 Cite the comment from @mizvekov in //github.com/llvm/issues/79240: > There are two kinds of bugs / issues relevant here: > > Clang bugs that this change hides > Here we can add a Frontend flag that disables the GMF ODR check, just > so > we can keep tracking, testing and fixing these issues. > The Driver would just always pass that flag. > We could add that flag in this current issue. > Bugs in user code: > I don't think it's worth adding a corresponding Driver flag for > controlling the above Frontend flag, since we intend it's behavior to > become default as we fix the problems, and users interested in testing > the more strict behavior can just use the Frontend flag directly. This patch follows the suggestion: - Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default off, so that the every existing test will still be tested with checking ODR violations. - Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior we intended. - Edit the document to tell the users who are still interested in more strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the existing behavior.
a freebsd dev member reported a symbol conflict and intercepting this had little value anyway. (cherry picked from commit 16a1ef8)
This action is really just a wrapper around cmake and ninja. It doesn't add any value to the builds, and I don't think we need it now that there are reusable workflows. (cherry picked from commit d25022b)
There is more space available on /mnt (~56G) than on / (~30G), and we are starting to see some of the CI jobs run out of disk space on Linux. (cherry picked from commit 1a64260)
This crash is basically caused by calling `ASTContext::getRawCommentForDeclNoCacheImp` with its input arguments `RepresentativeLocForDecl` and `CommentsInTheFile` refering to different files. A reduced reproducer is provided in this patch. After the source locations for instantiations of funtion template are corrected in the commit 256a0b2, the variable `CommitsInThisFile` in the function `ASTContext::attachCommentsToJustParsedDecls` would refer to the source file rather than the header file for implicit function template instantiation. Therefore, in the first loop in `ASTContext::attachCommentsToJustParsedDecls`, `D` should also be adjusted for relevant scenarios like the second loop. Fixes llvm#67979 Fixes llvm#68524 Fixes llvm#70550 (cherry picked from commit 5f4ee5a)
…lvm#80681) The TargetGuard fields for 'svldr[_vnum]_za' and 'svstr[_vnum]_za' were incorrectly set to `+sve` instead of `+sme`. This means that compiling code that uses these intrinsics requires compiling for both `+sve` as well as `+sme`. This PR also fixes the target guards for the `svadd` and `svsub` builtins that are enabled under `+sme2,+sme-i16i64` and `+sme2,+sme-f64f64`, as it initially did the following: ``` let TargetGuard = "+sme2" in { let TargetGuard = "+sme-i16i64" in { // Builtins defined here will be predicated only by // '+sme-i16i64', and not '+sme2,+sme-i16i64'. } } ``` This PR also removes `-target-feature +sve` from all the SME tests, to ensure that the SME features are sufficient to build the tests. (cherry picked from commit 3d186a7)
Fix llvm#79283: `test/dfsan/custom.cpp` has undefined symbol linker errors on glibc 2.38 due to lack of wrappers for `__isoc23_strtol` and `__isoc23_scanf` family functions. Implement these wrappers as aliases to existing wrappers, similar to https://reviews.llvm.org/D158943 for other sanitizers. `strtol` in a user program, whether or not `_ISOC2X_SOURCE` is defined, uses the C23 semantics (`strtol("0b1", 0, 0)` => 1), when `libclang_rt.dfsan.a` is built on glibc 2.38+. (cherry picked from commit 6485600)
C23 has `bool`, but logical operators still return int. Check that we're not in C to avoid false-positive -Wconstant-logical-operand. Fixes llvm#64356 (cherry picked from commit a18e92d)
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com> (cherry picked from commit 4520b47)
Commit d813af7 addressed a regression introduced by commit 3791b3f but caused `clang-format -dump-config` to "hang". This patch reverts changes to ClangFormat.cpp by both commits and reworks the cleanup. Fixes llvm#80621. (cherry picked from commit 8f6e13e)
This reverts commit dc61ebb. See llvm#76733 (comment). (cherry picked from commit a628f68)
OpFlag and WrapperKind should be chosen consistently with each other in regards to PIC, otherwise we hit asserts later on. Broken by c04a05d. Fixes llvm#80831. (cherry picked from commit 5a83bcc)
… but erased (llvm#79820) Fixes llvm#79718. Fixes llvm#71178. The same instructions may exist in an iteration. We cannot immediately delete instructions in `ErasedInstrs`. (cherry picked from commit 95b14da)
-DLIBCXX_ENABLE_UNICODE=OFF or -D_LIBCPP_HAS_NO_UNICODE doesn't build without this change. (cherry picked from commit 30cd183)
…m#81326) The SOURCE_DATE_EPOCH environment variable can be set in order to get reproducible build. When linking PE/COFF modules with LLD, the timestamp field is set to the current time, unless either the /timestamp: or /Brepro option is set. If neither of them is set, check the SOURCE_DATE_EPOCH variable, before resorting to using the actual current date and time. See https://reproducible-builds.org/docs/source-date-epoch/ for reference on the use of this variable. (cherry picked from commit 0df8aed)
The buildbot test running on s390x platform keeps failing since [this time](https://lab.llvm.org/buildbot/#/builders/199/builds/31136). This is because of the dependency on the endianness of the platform. It expects the format invalid in the big endian platform (s390x). We can simply skip it. See: https://discourse.llvm.org/t/mlir-s390x-linux-failure/76695 (cherry picked from commit 65ac8c1)
…bj (llvm#81463) If llvm-readobj is built with a 32 bit time_t, it can't print such timestamps correctly. (cherry picked from commit 0bf4ff2)
If we have something like G_TRUNC from v2s32 to v2s16, then lowering this to a concat of two G_TRUNC s32 to s16 followed by G_TRUNC from v2s16 to v2s8 does not bring us any closer to legality. In fact, the first part of that is a G_BUILD_VECTOR whose legalization will produce a new G_TRUNC from v2s32 to v2s16, and both G_TRUNCs will then get combined to the original, causing a legalization cycle. Make the lowering condition more precise, by requiring that the original vector is >128 bits, which is I believe the only case where this specific splitting approach is useful. Note that this doesn't actually produce a legal result (the alwaysLegal is a lie, as before), but it will cause a proper globalisel abort instead of an infinite legalization loop. Fixes llvm#81244. (cherry picked from commit 070848c)
…#89827) This is missing e.g. on Windows. With this change, it's possible to make the libcxx std module work on mingw-w64 (although that requires a few fixes to those headers). In the regular cstdlib header, we have _LIBCPP_USING_IF_EXISTS flagged on every single reexported function (since a9c9183), but the modules seem to only have _LIBCPP_USING_IF_EXISTS set on a few individual functions, so far. (cherry picked from commit 91526d6)
…OfShiftedLogic DAGCombiner is trying to fold shl over binops, and in the process combining it with another shl. However it needs to be more careful to ensure that the sum of the shift counts fits in the type used for the shift amount. For example, X86 is using i8 as shift amount type. So we need to make sure that the sum of the shift amounts isn't greater than 255. Fix will be applied in a later commit. This only pre-commits the test case to show that we currently get the wrong result. Bug was found when testing the C23 BitInt feature. (cherry picked from commit 5fd9bbd)
…89616) Ensure that the sum of the shift amounts does not overflow the shift amount type when combining shifts in combineShiftOfShiftedLogic. Solves a miscompile bug found when testing the C23 BitInt feature. Targets like X86 that only use an i8 for shift amounts after legalization seems to be extra susceptible for bugs like this as it isn't legal to shift more than 255 steps. (cherry picked from commit f9b419b)
Iterator MI can advance in insertWait() but we need original instruction to set temporal hint. Just move it before handling volatile.
…vm#86624) Fixes llvm#86559. (cherry picked from commit a7f4576)
Commit d06b923 caused a regression that breaks after a block comment adjacent to a function paramter that follows. Fixes llvm#86573. (cherry picked from commit d61edec)
…vm#88671) Linked to gnustep/libobjc2#289. More information can be found in issue: llvm#88273. My solution involves creating a new message-send function for this calling convention when targeting MSVC. Additional information is available in the libobjc2 pull request. I am unsure whether we should check for a runtime version where objc_msgSend_stret2_np is guaranteed to be present or leave it as is, considering it remains a critical bug. What are your thoughts about this @davidchisnall? (cherry picked from commit 3dcd2cc)
…lvm#89967) Fixes llvm#89959. (cherry picked from commit 22da5a6)
A struct that declares an inner struct, but no fields, won't have a field count. So getting the offset of the inner struct fails. This happens in both C and C++: struct foo { struct bar { int Quantizermatrix[]; }; }; Here 'struct foo' has no fields. Closes: llvm#88931
See the following case: ``` define i8 @SRC1(i8 %x) { entry: %cmp = icmp eq i8 %x, -1 br i1 %cmp, label %exit, label %if.then if.then: %inc = add nuw nsw i8 %x, 1 br label %exit exit: %retval = phi i8 [ %inc, %if.then ], [ -1, %entry ] ret i8 %retval } define i8 @tgt1(i8 %x) { entry: %inc = add nuw nsw i8 %x, 1 %0 = icmp eq i8 %inc, 0 br i1 %0, label %exit, label %if.then if.then: ; preds = %entry br label %exit exit: ; preds = %if.then, %entry %retval = phi i8 [ %inc, %if.then ], [ -1, %entry ] ret i8 %retval } ``` `optimizeBranch` converts `icmp eq X, -1` into cmp to zero on RISC-V and hoists the add into the entry block. Poison-generating flags should be dropped as they don't still hold. Proof: https://alive2.llvm.org/ce/z/sP7mvK Fixes llvm#90380 (cherry picked from commit ab12bba)
Fixes llvm#90356 (cherry picked from commit 35b89dd)
…sn't have valid source locations (llvm#89564) Fixes llvm#86998 (cherry picked from commit c1b6cca)
These were added in https://reviews.llvm.org/D14208, which look like they attempt to detect abs from xor+add+ashr. They do not appear to be detecting the correct value for the src input though, which I think is intended to be the sub(zext, zext) part of the pattern. We have pattens from abs now, so the old invalid patterns can be removed. Fixes llvm#88784 (cherry picked from commit 851462f)
Until we can reliably check the legality and improve our selection of these, don't form them at all. (cherry picked from commit 60fc4ac)
This is used when -march=native run on an unknown CPU to old version of LLVM. (cherry picked from commit b329179)
…ex expr as 0. (llvm#90375) During analysis, we incorrectly leave the offset part of an address info struct as zero, when in actual fact we failed to decompose it into base + offset. This results in incorrectly assuming that the address is adjacent to another store addr. To fix this we wrap the offset in an optional<> so we can distinguish between real zero and unknown. Fixes issue llvm#90242 (cherry picked from commit 19f4d68)
``` SelectionDAG has 17 nodes: t0: ch,glue = EntryToken t6: i64,ch = CopyFromReg t0, Register:i64 %2 t8: i1 = truncate t6 t4: i64,ch = CopyFromReg t0, Register:i64 %1 t7: i1 = truncate t4 t2: i64,ch = CopyFromReg t0, Register:i64 %0 t10: i64,i1 = saddo t2, Constant:i64<1> t11: i1 = or t8, t10:1 t12: i1 = select t7, t8, t11 t13: i64 = any_extend t12 t15: ch,glue = CopyToReg t0, Register:i64 $x10, t13 t16: ch = RISCVISD::RET_GLUE t15, Register:i64 $x10, t15:1 ``` `OtherOpVT` should be i1, but `OtherOp->getValueType(0)` returns `i64`, which ignores `ResNo` in `SDValue`. Fix llvm#90652. (cherry picked from commit 2647bd7)
…lvm#90151) In the context of determining whether a class counts as an "aggregate", a constructor template counts as a user-provided constructor. Fixes llvm#86384 (cherry picked from commit 3ab4ae9)
It allows to control of error output for the function.
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write If you have received no comments on your PR for a week, you can request a review If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
if constexpr
withExprWithCleanups
([coverage] fix crash in code coverage andif constexpr
withExprWithCleanups
#80292)TemplateArgument::Declaration
([clang] Represent array refs asTemplateArgument::Declaration
#80050)Decision
beforeExpansion
(CoverageMappingWriter: EmitDecision
beforeExpansion
#78966)Decision
take account of expansions ([Coverage] LetDecision
take account of expansions #78969)shl nuw nsw
andllvm.umin
#78621.-Wconstant-logical-operand
in C23 ([clang] Fix unexpected-Wconstant-logical-operand
in C23 #80724)ErasedInstrs
but erased ([RegisterCoalescer] Clear instructions not recorded inErasedInstrs
but erased #79820)getFlippedStrictnessPredicateAndConstant
MSB
value ([LoongArch] Make sure that the LoongArchISD::BSTRINS node uses the correctMSB
value #84454)wasm32-wasip2
([WebAssembly] Change the default linker forwasm32-wasip2
#84569)memcpy
replace with trivial auto var init#
when building for Arm64EC (Prepend all library intrinsics with#
when building for Arm64EC #87542)combineCarryDiamond
([SelectionDAG] Prevent combination on inconsistent type incombineCarryDiamond
#84888)foldSelectWithSRem
( [InstCombine] Fix unexpected overwriting infoldSelectWithSRem
#89539)InductiveRangeCheck::parseRangeCheckICmp
([IRCE] Skip icmp ptr inInductiveRangeCheck::parseRangeCheckICmp
#89967)ImplicitValueInitExpr
#89564)tryFoldSelectIntoOp
([RISCV][ISel] Fix types intryFoldSelectIntoOp
#90659)