merge main into amd-staging #410
Closed
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
Check for lack of `setter` and `getter` attributes on `DIObjCProperty`
…lvm#165298) We already have the same test (just different variable names) in `property-basic.m`.
Generate s_absdiff_i32. Tested in absdiff.ll. Also update s_cmp_0.ll to test that s_absdiff_i32 is foldable with a s_cmp_lg_u32 sX, 0. --------- Signed-off-by: John Lu <[email protected]>
This reverts commit d818434.
…k LLVM IR (llvm#165297) This patch series renames these Objective-C property tests to something more descriptive and adjusts them to check IR. Currently the tests check raw assembly output (not even dwarfdump). Which most likely hid some bugs around property debug-info.
New name makes it easer to find and checking IR is less likely to hide bugs (and is more consistent with the other Clang debug-info tests).
This reverts commit 8f1c72d. This is causing builtbot failures. https://lab.llvm.org/buildbot/#/builders/23/builds/15030 https://lab.llvm.org/buildbot/#/builders/190/builds/29834
00f5a1e added in some new tests that fail under the profcheck configuration. We have not finished cleaning up SimplifyCFG yet, so disable these tests for now.
llvm#165046) This options sets a compile option when building sources inside the string directory, and this option affects string_utils.h. But string_utils.h is #included from more places than just the string directory (such as from __support/CPP/string.h), leading to both narrow-reads in those cases, but more seriously, ODR violations when the two different string_length implementations are included int he same program. Having this option at the top level avoids this problem.
This PR adds the code of Boost.Math as of version 1.89 into the third-party directory, as discussed in a recent RFC [1]. The goal is for this code to be used as a back-end for the C++17 Math Special Functions. As explained in third-paty/README.md, this code is cleared for usage inside libc++ for the Math Special functions, however the LLVM Foundation should be consulted before using this code anywhere else in the LLVM project, due to the fact that it is under the Boost Software License (as opposed to the usual LLVM license). See the RFC [1] for more details. [1]: https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on-boost-math-for-the-c-17-math-special-functions
) `Reloc::length` actually encodes the log2 of the length. Thanks @int3 for pointing this out in llvm#160894 (comment). This code computes hashes of relocations. With the correct length, the hashes should more accurately represent the relocation. In my testing of some large binaries, the compressed size change is negligable.
So it's treated as a comment and doesn't need to be manually removed from the output when used as IR.
llvm#162722 introduced a regression that started creating initializers for CDEFINED variables. CDEFINED variables cannot have initializers, because their storage is expected come from elsewhere, likely outside of Fortran. Fixed the regression and improved the regression test to catch the incorrect initialization case. Also, based on the code review feedback, made CDEFINED variable initialization a hard error and updated tests accordingly.
…#165175) Started running `clang-tidy` on our clang-tidy headers. This part covers what `clang-tidy` could fix automatically (with `--fix` option). The main goal is to enable `HeaderFilterRegex: 'clang-tools-extra/clang-tidy/.*'` eventually in config.
In DXIL, some 64bit types are actually represented with their 32bit counterpart. This was already being address in the codegen, however the metadata generation was lacking this information. This PR is fixing this issue. Closes: [llvm#146735](llvm#146735)
In `Driver.cpp` `std::atomic<uint64_t>` is used which may need
libatomic.
Build failure (if that is of interest):
```
[127/135] Linking CXX shared library lib/liblldMachO.so.20.1
ninja: job failed: : && /usr/lib/ccache/bin/clang++-20 -fPIC -Os -fstack-clash-protection -Wformat -Werror=format-security -D_GLIBCXX_ASSERTIONS=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -D_LIBCPP_ENABLE_HARDENED_MODE=1 -g -O2 -DNDEBUG -g1 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wl,--as-needed,-O1,--sort-common -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/home/user/aports/main/lld20/src/lld-20.1.5.src/build/./lib -Wl,--gc-sections -shared -Wl,-soname,liblldMachO.so.20.1 -o lib/liblldMachO.so.20.1 MachO/CMakeFiles/lldMachO.dir/Arch/ARM64.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/ARM64Common.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/ARM64_32.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/X86_64.cpp.o MachO/CMakeFiles/lldMachO.dir/ConcatOutputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o MachO/CMakeFiles/lldMachO.dir/DriverUtils.cpp.o MachO/CMakeFiles/lldMachO.dir/Dwarf.cpp.o MachO/CMakeFiles/lldMachO.dir/EhFrame.cpp.o MachO/CMakeFiles/lldMachO.dir/ExportTrie.cpp.o MachO/CMakeFiles/lldMachO.dir/ICF.cpp.o MachO/CMakeFiles/lldMachO.dir/InputFiles.cpp.o MachO/CMakeFiles/lldMachO.dir/InputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/LTO.cpp.o MachO/CMakeFiles/lldMachO.dir/MapFile.cpp.o MachO/CMakeFiles/lldMachO.dir/MarkLive.cpp.o MachO/CMakeFiles/lldMachO.dir/ObjC.cpp.o MachO/CMakeFiles/lldMachO.dir/OutputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/OutputSegment.cpp.o MachO/CMakeFiles/lldMachO.dir/Relocations.cpp.o MachO/CMakeFiles/lldMachO.dir/BPSectionOrderer.cpp.o MachO/CMakeFiles/lldMachO.dir/SectionPriorities.cpp.o MachO/CMakeFiles/lldMachO.dir/Sections.cpp.o MachO/CMakeFiles/lldMachO.dir/SymbolTable.cpp.o MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o MachO/CMakeFiles/lldMachO.dir/SyntheticSections.cpp.o MachO/CMakeFiles/lldMachO.dir/Target.cpp.o MachO/CMakeFiles/lldMachO.dir/UnwindInfoSection.cpp.o MachO/CMakeFiles/lldMachO.dir/Writer.cpp.o -L/usr/lib/llvm20/lib -Wl,-rpath,"\$ORIGIN/../lib:/usr/lib/llvm20/lib:/home/user/aports/main/lld20/src/lld-20.1.5.src/build/lib:" lib/liblldCommon.so.20.1 /usr/lib/llvm20/lib/libLLVM.so.20.1 && :
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o: in function `handleExplicitExports()':
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:501:(.text._ZL21handleExplicitExportsv+0xb8): undefined reference to `__atomic_load_8'
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: /usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:501:(.text._ZL21handleExplicitExportsv+0x180): undefined reference to `__atomic_load_8'
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o: in function `void llvm::function_ref<void (unsigned int)>::callback_fn<llvm::parallelForEach<lld::macho::Symbol* const*, handleExplicitExports()::$_0>(lld::macho::Symbol* const*, lld::macho::Symbol* const*, handleExplicitExports()::$_0)::{lambda(unsigned int)#1}>(int, unsigned int)':
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:631:(.text._ZN4llvm12function_refIFvjEE11callback_fnIZNS_15parallelForEachIPKPN3lld5macho6SymbolEZL21handleExplicitExportsvE3$_0EEvT_SC_T0_EUljE_EEvij+0xd4): undefined reference to `__atomic_fetch_add_8'
clang++-20: error: linker command failed with exit code 1 (use -v to see invocation)
```
CC @int3 @gkmhub @smeenai
Similar to
llvm@f0b451c
We shouldn't just consider the dynamic dimensions, but all output dimensions for the value bounds constraints. The previous test just worked because the dynamic dimension was on the first position.
…ction creation (llvm#165315) Should set the insertion point appropriately before we create an instruction with IRBuilder. Fixes: SWDEV-562571
…nonicalizations.cpp (NFC)
…ofitable (llvm#160483) Skip the transform that replaces: %a = trunc i64 %x to i16 %b = sext i16 %a to i32 with %a = trunc i64 %x to i32 %b = shl i32 %a, 16 %c = ashr exact i32 %b, 16 when (pre-trunc) source type is wider than the final destination type. Modern architectures typically have efficient sign-extend instruction. It is preferable to preserve the sext for this case. Resolves llvm#116019 Also fold sext(trunc nsw) to trunc nsw when narrowing source.
--[no-]offloadlib option is used by rocm and cuda toolchain to enable/disable device libraries in linking phase for device code. It makes sense to re-use this option in SYCL for similar purpose and since clang driver supports SYCL in CL compatibility mode, we also need to enable this option in CL compatibility mode. --------- Signed-off-by: jinge90 <[email protected]>
…d. (llvm#165305) `MCInstrDesc` counts the SWZ operand for `NumOperands` -- thus, since we do not parse this into the `MCInst` operands, there will be a mismatch between `MCInst.getNumOperands` and `MCInstrDesc.getNumOperands` . `llvm-mca` assumes that each operand counted by `MCInstrDesc.getNumOperands` will be present in `MCInst.operands` https://github.com/llvm/llvm-project/blob/263377a17570e1cbe6eeae9ffa5ce02f240839ef/llvm/lib/MCA/InstrBuilder.cpp#L324 This parses a dummy operand for the buffer_loads as a placeholder for the implicit SWZ operand. This is similar to the parsing of `tbuffer_` variants which automatically parse the dummy operand https://github.com/llvm/llvm-project/blob/263377a17570e1cbe6eeae9ffa5ce02f240839ef/llvm/utils/TableGen/AsmMatcherEmitter.cpp#L1853
…ming` (llvm#162160) Add more constexpr options to `readability-identifier-naming` check such as: - `ClassConstexpr*` - `GlobalConstexprVariable*` - `LocalConstexprVariable*` - `StaticConstexprVariable*` closes llvm#54110
…lvm#165127) This code: ```cpp void f() { std::lock_guard<std::mutex> dont_crash {some_nonexistant_variable}; } ``` Generates an AST like this: ```txt TranslationUnitDecl `-FunctionDecl <line:3:1, line:5:1> line:3:6 f 'void ()' `-CompoundStmt <col:10, line:5:1> `-DeclStmt <line:4:3, col:69> `-VarDecl <col:3, col:31> col:31 dont_crash 'std::lock_guard<std::mutex>' destroyed ``` Where the `VarDecl` has no initializer. The check doesn't expect this and crashes.
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.
No description provided.