Release/13.x #358
Closed
Release/13.x #358
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
This was reverted due to a reported crash. This reverts commit 796b84d.
Differential Revision: https://reviews.llvm.org/D106770
Don't prefer python2's virtualenv when setting up the test-suite. Always use python3 instead, since that's what we support everywhere else anyway. Differential Revision: https://reviews.llvm.org/D106941
This amends c5243c6 to fix formatting continued function calls with BinPacking = false. Differential Revision: https://reviews.llvm.org/D106773 (cherry picked from commit 75f6a79)
…ather/scatter An incorrect mask type when lowering an SVE gather/scatter was causing a codegen fault which manifested as the incorrect predicate size being used for an SVE gather/scatter, (e.g.. p0.b rather than p0.d). Fixes PR51182. Differential Revision: https://reviews.llvm.org/D106943 (cherry picked from commit 191831e)
When we have a terminator sequence (i.e. a tailcall or return), MIIsInTerminatorSequence is used to work out where the preceding ABI-setup instructions end, i.e. the parts that were glued to the terminator instruction. This allows LLVM to split blocks safely without having to worry about ABI stuff. The function only ignores DBG_VALUE instructions, meaning that the two debug instructions I recently added can end terminator sequences early, causing various MachineVerifier errors. This patch promotes the test for debug instructions from "isDebugValue" to "isDebugInstr", thus avoiding any debug-info interfering with this function. Differential Revision: https://reviews.llvm.org/D106660 (cherry picked from commit 8612417)
This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL
STT_FUNC definitions.
The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline
function, a template instantiation) seen by a -Bsymbolic-functions linked
shared object may be different from the address seen from outside the shared
object. Such cases are uncommon. (ELF/Mach-O programs may use
`-fvisibility-inlines-hidden` to break such pointer equality. On Windows,
correct dllexport and dllimport are needed to make pointer equality work.
Windows link.exe enables /OPT:ICF by default so different inline functions may
have the same address.)
```
// a.cc -> a.o -> a.so (-Bsymbolic-functions)
inline void f() {}
void *g() { return (void *)&f; }
// b.cc -> b.o -> exe
// The address is different!
inline void f() {}
```
-Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of
-Bsymbolic-functions, which can make such programs work.
Implementations usually emit a vague linkage definition in a COMDAT group. We
could detect the group (with more code) but I feel that we should just check
STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch
for rare cases when users want interposition on definitions.
GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871
Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic
If Linux distributions migrate to protected non-vague-linkage external linkage
functions by default, the linker option can still be handy because it allows
rapid experiment without recompilation. Protected function addresses currently
have deep issues in GNU ld.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D102570
(cherry picked from commit b06426d)
Includes regression test for problem noted by @hans. This reverts commit 973de71. Differential Revision: https://reviews.llvm.org/D106898 (cherry picked from commit 0871954)
This feature requires support of __opencl_c_images, so diagnostics for that is provided as well. Also, ensure that cl_khr_3d_image_writes feature macro is set to the same value. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D106260 (cherry picked from commit f16a4fc)
In LLVM IR terms the ACLE type 'data512_t' is essentially an aggregate
type { [8 x i64] }. When emitting code for inline assembly operands,
clang tries to scalarize aggregate types to an integer of the equivalent
length, otherwise it passes them by-reference. This patch adds a target
hook to tell whether a given inline assembly operand is scalarizable
so that clang can emit code to pass/return it by-value.
Differential Revision: https://reviews.llvm.org/D94098
Adds MVT::i64x8, a Machine Value Type needed for lowering inline assembly operands which materialize a sequence of eight general purpose registers. Differential Revision: https://reviews.llvm.org/D94096
This patch legalizes the Machine Value Type introduced in D94096 for loads and stores. A new target hook named getAsmOperandValueType() is added which maps i512 to MVT::i64x8. GlobalISel falls back to DAG for legalization. Differential Revision: https://reviews.llvm.org/D94097
@tcanens pointed out the current behavior of the macro breaks the usage pattern described in http://wg21.link/SD6 ``` ``` To support this usage pattern the hard errror is removed. Instead the header includes nothing but the `<version>` header. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D107134 (cherry picked from commit d618a1c)
'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while parsing and then later on check for language options to construct actual pipe. This feature requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well. This is the same patch as in D106748 but with a tiny fix in checking of diagnostic messages. Also added tests when program scope global variables are not supported. This is squashed cherry pick of D107154 and D107176
Use `clang_target_link_libraries` to avoid duplicate libraries when
the same symbol is provided both by a static library and a larger
dylib, fixing linking with win32 dylibs. This fixes errors like
these:
ld.lld: error: duplicate symbol: llvm::createStringError(std::__1::error_code, char const*)
>>> defined at libLLVMSupport.a(Error.cpp.obj)
>>> defined at libLLVM-14git.dll
This matches how other clang tools declare their dependencies.
Differential Revision: https://reviews.llvm.org/D107231
(cherry picked from commit 25a288b)
Postgresql uses `--stack=` in its Makefile. Downstream issue: msys2/MINGW-packages#9167 Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D107237 (cherry picked from commit 05b025e)
(cherry picked from commit 7546a34)
The sign_extend we insert here can get turned into a zero_extend if the sign bit is known zero. This can enable a setcc combine that shrinks compares with zero_extend. This reduces the use count of the zero_extend allowing other combines to turn it back into an any_extend. This restricts the combine to only cases where the result is used by a CopyToReg. This works for my original motivating case. I hope the CopyToReg use will prevent any converted extends from turning back into an any_extend. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D106754 (cherry picked from commit 54588bc)
This transform was added with e38b7e8 and as shown in: https://llvm.org/PR51241 ...it could crash without an extra check of the blocks. There might be a more compact way to write this constraint, but we can't just count the successors/predecessors without affecting a test that includes a switch instruction. (cherry picked from commit 5b83261)
There's a generic combine for these, but no test coverage. It's not clear if this is actually a good fold. The combine was added with D58874, but it has a bug that can cause crashing ( https://llvm.org/PR51238 ). (cherry picked from commit e427077)
This transform was added with D58874, but there were no tests for overflow ops. We need to change this one way or another because it can crash as shown in: https://llvm.org/PR51238 Note that if there are no uses of an overflow op's bool overflow result, we reduce it to a regular math op, so we continue to fold that case either way. If we have uses of both the math and the overflow bool, then we are likely not saving anything by creating an independent sub instruction as seen in the test diffs here. This patch makes the behavior in SDAG consistent with what we do in instcombine AFAICT. Differential Revision: https://reviews.llvm.org/D106983 (cherry picked from commit fa6b2c9)
This reverts commit ae6b400. llvm.org/PR51300
This reverts commit 5d1df6d. There is a strong objection to this change: https://reviews.llvm.org/D106436#2905618 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D106847 (cherry picked from commit 440e936)
(cherry picked from commit 6569b7f)
When using `-DLLVM_ENABLED_RUNTIMES` instead of `-DLLVM_ENABLED_PROJECTS` the `llvm-omp-device-info` tool is not compiled or installed. In general, no llvm tool would be build on runtimes, because the -DLLVM_BUILD_TOOLS flag is removed by the way runtimes compilation calls cmake again. This patch is simple. Just forward the value of this flag to the runtime cmake command. I'm also removing an unnecessary comment in the compilation of the tool Differential Revision: https://reviews.llvm.org/D107177 (cherry picked from commit 5424cee)
The check for size_t parameter 1 was already here for snprintf_chk, but it wasn't applied to regular snprintf. This could lead to mismatching and eventually crashing as shown in: https://llvm.org/PR50885 (cherry picked from commit 7f55557)
…CHECKS The `DataLayout` class currently contains the member `layoutStack` which is hidden behind a preprocessor region dependant on the NDEBUG macro. Code wise this makes a lot of sense, as the `layoutStack` is used for extra assertions that users will want when compiling a debug build. It however has the uncomfortable consequence of leading to a different ABI in Debug and Release builds. This I think is a bit annoying for downstream projects and others as they may want to build against a stable Release of MLIR in Release mode, but be able to debug their own project depending on MLIR. This patch changes the related uses of NDEBUG to LLVM_ENABLE_ABI_BREAKING_CHECKS. As the macro is computed at configure time of LLVM, it may not change based on compiler settings of a downstream projects like NDEBUG would. Differential Revision: https://reviews.llvm.org/D107227 (cherry picked from commit 97335ad)
When substitution failed on the first constrained template argument (but only the first), we would assert / crash. Checking for failure was only being performed from the second constraint on. This changes it so the checking is performed in that case, and the code is also now simplified a little bit to hopefully avoid this confusion. Signed-off-by: Matheus Izvekov <[email protected]> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D106907
This adds a new command for writing memory tags. It is based on the existing "memory write" command. Syntax: memory tag write <address-expression> <value> [<value> [...]] (where "value" is a tag value) (lldb) memory tag write mte_buf 1 2 (lldb) memory tag read mte_buf mte_buf+32 Logical tag: 0x0 Allocation tags: [0xfffff7ff9000, 0xfffff7ff9010): 0x1 [0xfffff7ff9010, 0xfffff7ff9020): 0x2 The range you are writing to will be calculated by aligning the address down to a granule boundary then adding as many granules as there are tags. (a repeating mode with an end address will be in a follow up patch) This is why "memory tag write" uses MakeTaggedRange but has some extra steps to get this specific behaviour. The command does all the usual argument validation: * Address must evaluate * You must supply at least one tag value (though lldb-server would just treat that as a nop anyway) * Those tag values must be valid for your tagging scheme (e.g. for MTE the value must be > 0 and < 0xf) * The calculated range must be memory tagged That last error will show you the final range, not just the start address you gave the command. (lldb) memory tag write mte_buf_2+page_size-16 6 (lldb) memory tag write mte_buf_2+page_size-16 6 7 error: Address range 0xfffff7ffaff0:0xfffff7ffb010 is not in a memory tagged region (note that we do not check if the region is writeable since lldb can write to it anyway) The read and write tag tests have been merged into a single set of "tag access" tests as their test programs would have been almost identical. (also I have renamed some of the buffers to better show what each one is used for) Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D105182 (cherry picked from commit 6a7a2ee)
Commits 58494c8, f6bc614, and 0fc27ef added special handlings for K&R C function definitions and caused some JavaScript/TypeScript regressions which were addressed in D107267, D108538, and D108620. This patch would have prevented these known regressions and will fix any unknown ones. Differential Revision: https://reviews.llvm.org/D109582 (cherry picked from commit 3205dd3)
Users of VPValues are managed in a vector, so we need to be more careful when iterating over users while updating them. For now, just copy them. Fixes 51798. (cherry picked from commit 368af75)
(cherry picked from commit 71052ea)
…se notes Differential Revision: https://reviews.llvm.org/D109642
This is essentially what D106813 was supposed to do but did not. Differential revision: https://reviews.llvm.org/D108919 (cherry picked from commit c9948e9)
See PR51842. This fixes an assert firing in the static analyzer, triggered by implicit moves in blocks in C mode: This also simplifies the AST a little bit when compiling non C++ code, as the xvalue implicit casts are not inserted. We keep and test that the nrvo flag is still being set on the VarDecls, as that is still a bit beneficial while not really making anything more complicated. Signed-off-by: Matheus Izvekov <[email protected]> Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D109654 (cherry picked from commit 2d6829b)
9ee64c3 has started using COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG inside scudo. However, the relevant CMake check was performed in builtin-config-ix.cmake, so the definition was missing when builtins were not built. Move the check to config-ix.cmake, so that it runs unconditionally of the components being built. Fixes PR#51847 Differential Revision: https://reviews.llvm.org/D109812 (cherry picked from commit 210d72e)
After D94315 we add the `NoInline` attribute to the outlined function to handle data environments in the OpenMP if clause. This conflicted with the `AlwaysInline` attribute added to the outlined function. for better performance in D106799. The data environments should ideally not require NoInline, but for now this fixes PR51349. Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D107649 (cherry picked from commit 41a6b50)
(cherry picked from commit 454f69b)
(cherry picked from commit 3db9590)
There needs to be a blank line after ".. code-block:: <lang>".
Differential Revision: https://reviews.llvm.org/D109349 (cherry picked from commit b588f5d)
…o vectors (PR51858) When searching for hidden identity shuffles (added at rG41146bfe82aecc79961c3de898cda02998172e4b), only peek through bitcasts to the source operand if it is a vector type as well. (cherry picked from commit dcba994)
Add a release note for the renaming of the debuginfo-test to cross-project-tests, performed in commit 1364750 and follow-ons. Reviewed by: sylvestre.ledru Differential Revision: https://reviews.llvm.org/D110134
Currently, we use SExtValue to decide whether to invert tbz or tbnz. However, for the case zext (xor x, c), we should use ZExt rather than SExt otherwise we will generate totally opposite branches. Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D108755 (cherry picked from commit 5f48c14)
Previously in D104261 we warned about dropping locks from back edges, this is the corresponding change for exclusive/shared joins. If we're entering the loop with an exclusive change, which is then relaxed to a shared lock before we loop back, we have already analyzed the loop body with the stronger exclusive lock and thus might have false positives. There is a minor non-observable change: we modify the exit lock set of a function, but since that isn't used further it doesn't change anything. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D106713 (cherry picked from commit 9b889f8)
Differential Revision: https://reviews.llvm.org/D108912
See PR51862. The consumers of the Elidable flag in CXXConstructExpr assume that an elidable construction just goes through a single copy/move construction, so that the source object is immediately passed as an argument and is the same type as the parameter itself. With the implementation of P2266 and after some adjustments to the implementation of P1825, we started (correctly, as per standard) allowing more cases where the copy initialization goes through user defined conversions. With this patch we stop using this flag in NRVO contexts, to preserve code that relies on that assumption. This causes no known functional changes, we just stop firing some asserts in a cople of included test cases. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D109800 (cherry picked from commit d9308aa)
clementval
pushed a commit
to clementval/llvm-project
that referenced
this pull request
Nov 3, 2021
* Move toward compilation of module data Remove DataStmt from the PFT (it's not needed), and do some of the set up for eventually processing module symbols. * review update
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`
keryell
pushed a commit
to keryell/llvm-project
that referenced
this pull request
Oct 19, 2024
Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`
kzhuravl
pushed a commit
to ROCm/llvm-project
that referenced
this pull request
Jan 31, 2025
…e_202501291026 merge main into amd-staging
xlauko
pushed a commit
to trailofbits/instafix-llvm
that referenced
this pull request
Mar 28, 2025
Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`
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.