summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump version to 14.0.6llvmorg-14.0.6release/14.xTom Stellard2022-06-228-9/+9
|
* [clang][AVR] Implement standard calling convention for AVR and AVRTinyBen Shi2022-06-221-278/+278
| | | | | | | | | | | This patch implements avr-gcc's calling convention: https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D120720 (cherry picked from commit 86c1d075bb32101fe1c403e873ce33945bfa9626)
* [AVR] Add more devicesBen Shi2022-06-224-2/+50
| | | | | | | | | | Synchronize AVR device lists with gcc-avr-5.4.0 and avr-libc-2.0.0. Reviewed By: dylanmckay, aykevl Differential Revision: https://reviews.llvm.org/D121359 (cherry picked from commit 6edfe45a63125a8938a5bea13534a118b0e31023)
* [MC][AArch64] Enable '+v8a' when nothing specified for MCSubtargetInfollvmorg-14.0.5CHIANG, YU-HSUN (Tommy Chiang, oToToT)2022-06-106-4/+48
| | | | | | | | | | | | | | | | | | | | | Since D110065, the 'R' profile support is added to LLVM. It turns the `generic` cpu into the intersection of v8-a and v8-r. However, this makes some backward compatibility problems. The original patch makes the clang driver implicitly pass -march=armv8-a when only the triple is specified. Since it only applies to clang, other tools like llvm-objdump still faces the backward compatibility problem. This patch applies the same idea to MC related tools by enabling '+v8a' feature when nothing is specified (both CPU and FS are empty) for MCSubtargetInfo creation. This patch should fix PR53956. Reviewed by: labrinea Differential Revision: https://reviews.llvm.org/D124319 (cherry picked from commit 4a31af88a26726f4662a2923618fe45977d09356)
* [analyzer] Fix null pointer deref in CastValueCheckerVince Bridgers2022-06-093-21/+50
| | | | | | | | | | | | | | A crash was seen in CastValueChecker due to a null pointer dereference. The fix uses QualType::getAsString to avoid the null dereference when a CXXRecordDecl cannot be obtained. A small reproducer is added, and cast value notes LITs are updated for the new debug messages. Reviewed By: steakhal Differential Revision: https://reviews.llvm.org/D127105 (cherry picked from commit c7fa4e8a8bc41e52cc49a27e0495d67d730fa167)
* PR45879: Fix assert when constant evaluating union assignment.Richard Smith2022-06-092-3/+35
| | | | | | | | | Consider the form of the first operand of a class assignment not the second operand when implicitly starting the lifetimes of union members. Also add a missing check that the assignment call actually came from a syntactic assignment, not from a direct call to `operator=`. (cherry picked from commit 30baa5d2a450d5e302d8cba3fc7a26a59d4b7ae1)
* [clang-tidy] `bugprone-use-after-move`: Fix handling of moves in lambda capturesMartin Boehme2022-06-093-1/+14
| | | | | | | | | | | | | | Previously, we were treating a move in the lambda capture as if it happened within the body of the lambda, not within the function that defines the lambda. This fixes the same bug as https://reviews.llvm.org/D119165 (which it appears may have been abandoned by the author?) but does so more simply. Reviewed By: njames93 Differential Revision: https://reviews.llvm.org/D126780 (cherry picked from commit 8b90b2539048a581052a4b0d7628ffba0cd582a9)
* [clang-format] Fix SpacesInLineCommentPrefix deleting tokens.Marek Kurdej2022-06-092-10/+14
| | | | | | | | Fixes https://github.com/llvm/llvm-project/issues/53799. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D119680
* [clang-format] Fix PointerAlignment: Right not working with tab indentation.Marek Kurdej2022-06-092-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://github.com/llvm/llvm-project/issues/55407. Given configuration: ``` UseTab: Always PointerAlignment: Right AlignConsecutiveDeclarations: true ``` Before, the pointer was misaligned in this code: ``` void f() { unsigned long long big; char *ptr; // misaligned int i; } ``` That was due to the fact that when handling right-aligned pointers, the Spaces were changed but StartOfTokenColumn was not. Also, a tab was used not only for indentation but for spacing too when using `UseTab: ForIndentation` config option: ``` void f() { unsigned long long big; char *ptr; // \t after char int i; } ``` Reviewed By: owenpan Differential Revision: https://reviews.llvm.org/D125528
* [LoopIdiom] Merge TBAA of adjacent stores when creating memsetStephen Long2022-06-082-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | Factor in the TBAA of adjacent stores instead of just the head store when merging stores into a memset. We were seeing GVN remove a load that had a TBAA that matched the 2nd store because GVN determined it didn't match the TBAA of the memset. The memset had the TBAA of only the first store. i.e. Loading the field pi_ of shared_count after memset to create an array of shared_ptr template<class T> class shared_ptr { T *p; shared_count refcount; }; class shared_count { sp_counted_base *pi_; }; Differential Revision: https://reviews.llvm.org/D122205 (cherry picked from commit e02f4976acbf086904bf3903348603cc0f04e6ad)
* [MIPS] Address instruction selection failure for abs.[sd]Simon Dardis2022-06-074-9/+379
| | | | | | | | | | | | | | | | | | | | Previously, the choice between the instruction selection of ISD::FABS was decided at the point of setting the MIPS target lowering operation choice either `Custom` lowering or `Legal`. This lead to instruction selection failures as functions could be marked as having no NaNs. Changing the lowering to always be `Custom` and directly handling the the cases where MIPS selects the instructions for ISD::FABS resolves this crash. Thanks to kray for reporting the issue and to Simon Atanasyan for producing the reduced test case. This resolves PR/53722. Differential Revision: https://reviews.llvm.org/D124651 (cherry picked from commit 938ed8ae99f92c19cfb92b76a7e20a72409df84a)
* [LoopIdiom] Fix bailout for aliasing in memcpy transform.Eli Friedman2022-06-072-17/+53
| | | | | | | | | | | | | | Commit dd5991cc modified the aliasing checks here to allow transforming a memcpy where the source and destination point into the same object. However, the change accidentally made the code skip the alias check for other operations in the loop. Instead of completely skipping the alias check, just skip the check for whether the memcpy aliases itself. Differential Revision: https://reviews.llvm.org/D126486 (cherry picked from commit abdf0da8009f272f6c3d6398cf63f9f0a8257637)
* [ARM] Fix MVE getShuffleCost legalized type checkDavid Green2022-06-072-1/+8
| | | | | | | | | The MVE shuffle costing for VREV instructions was making incorrect assumptions as to legalized vector types remaining as vectors. Add a quick check to ensure they are indeed vectors before attempting to get the number of elements. (cherry picked from commit 53be6ab25cb97338384b9a73a4eef47cf3b89f3b)
* [Support] Add missing <cstdint> header to Base64.hSergei Trofimovich2022-06-071-0/+1
| | | | | | | | | | | | | Without the change llvm build fails on this week's gcc-13 snapshot as: [ 91%] Building CXX object unittests/Support/CMakeFiles/SupportTests.dir/Base64Test.cpp.o In file included from llvm/unittests/Support/Base64Test.cpp:14: llvm/include/llvm/Support/Base64.h: In function 'std::string llvm::encodeBase64(const InputBytes&)': llvm/include/llvm/Support/Base64.h:29:5: error: 'uint32_t' was not declared in this scope 29 | uint32_t x = ((unsigned char)Bytes[i] << 16) | | ^~~~~~~~ (cherry picked from commit 5e9be93566f39ee6cecd579401e453eccfbe81e5)
* [Support] Add missing <cstdint> header to Signals.hSergei Trofimovich2022-06-071-0/+1
| | | | | | | | | | | | Without the change llvm build fails on this week's gcc-13 snapshot as: [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o In file included from llvm/lib/Support/Signals.cpp:14: llvm/include/llvm/Support/Signals.h:119:8: error: variable or field 'CleanupOnSignal' declared void 119 | void CleanupOnSignal(uintptr_t Context); | ^~~~~~~~~~~~~~~ (cherry picked from commit ff1681ddb303223973653f7f5f3f3435b48a1983)
* compiler-rt: Allow build without __c11_atomic_fetch_nandBrooks Davis2022-06-071-0/+3
| | | | | | | | | | | | | | | | Don't build atomic fetch nand libcall functions when the required compiler builtin isn't available. Without this compiler-rt can't be built with LLVM 13 or earlier. Not building the libcall functions isn't optimal, but aligns with the usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM 13 clang and no LLVM 14 clang is built. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D126710 (cherry picked from commit 18efa420da5fa065d88ba451cdcdbd950a2090c1)
* [clang-tidy] Fix #55134 (regression introduced by 5da7c04)Salman Javed2022-06-033-3/+24
| | | | | | | | | | | | | | | | | 5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the call to `getImmediateExpansionRange().getBegin()` with `getImmediateMacroCallerLoc()`, which has similar but subtly different behaviour. The consequence is that NOLINTs cannot suppress diagnostics when they are attached to a token that came from a macro **argument**, rather than elsewhere in the macro expansion. Revert to pre-patch behaviour and add test cases to cover this issue. Differential Revision: https://reviews.llvm.org/D126138 (cherry picked from commit 9ff4f2dfea632d63e3a57a88a2faa634aae5c772)
* [Local] Don't remove invoke of non-willreturn functionNikita Popov2022-06-032-1/+2
| | | | | | | The code was only checking for memory side-effects, but not for divergence side-effects. Replace this with a generic check. (cherry picked from commit 2e101cca690645d63ae4de1eb7b0e11d322448fd)
* [SimplifyCFG] Add test for invoke of nounwind non-willreturn function (NFC)Nikita Popov2022-06-031-11/+32
| | | | | | Test both the case with and without willreturn attribute. (cherry picked from commit 1f1de06165bb39f66049cdc942151fc6ed193123)
* [OpenMP] Fix partial unrolling off-by-one.Michael Kruse2022-06-029-22/+22
| | | | | | | | Even though the comment description is ".unroll_inner.iv < NumIterations", the code emitted a BO_LE ('<=') operator for the inner loop that is to be unrolled. This lead to one additional copy of the body code in a partially unrolled. It only manifests when the unrolled loop is consumed by another loop-associated construct. Fix by using the BO_LT operator instead. The condition for the outer loop and the corresponding code for tiling correctly used BO_LT already. Fixes #55236
* [clang][CUDA][Windows] Fix compilation error on Windows with `uint32_t ↵Evgeny Mankov2022-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | __nvvm_get_smem_pointer` The change fixes https://github.com/llvm/llvm-project/issues/54609 (the second reported issue) by eliminating a compilation error occurring only on Windows while trying to compile any CUDA source file by clang (-x cuda). [Repro] clang -x cuda <any_cu_source> [Error] __clang_cuda_runtime_wrapper.h:473: __clang_cuda_intrinsics.h(517,19): error GC871EEFB: unknown type name 'uint32_t'; did you mean 'cuuint32_t'? __device__ inline uint32_t __nvvm_get_smem_pointer(void *__ptr) { ^ C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.6/include\cuda.h:57:26: note: 'cuuint32_t' declared here typedef unsigned __int32 cuuint32_t; Reviewed By: tra Differential Revision: https://reviews.llvm.org/D122897 (cherry picked from commit c23147106f7efc4b5e29c47a08951116b4d994ac)
* [clang] Fix some clang->llvm type cache invalidation issuesArthur Eubanks2022-06-026-15/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take the following as an example struct z { z (*p)(); }; z f(); When we attempt to get the LLVM type of f, we recurse into z. z itself has a function pointer with the same type as f. Given the recursion, Clang simply treats z::p as a pointer to an empty struct `{}*`. The LLVM type of f is as expected. So we have two different potential LLVM types for a given Clang type. If we store one of those into the cache, when we access the cache with a different context (e.g. we are/aren't recursing on z) we may get an incorrect result. There is some attempt to clear the cache in these cases, but it doesn't seem to handle all cases. This change makes it so we only use the cache when we are not in any sort of function context, i.e. `noRecordsBeingLaidOut() && FunctionsBeingProcessed.empty()`, which are the cases where we may decide to choose a different LLVM type for a given Clang type. LLVM types for builtin types are never recursive so they're always ok. This allows us to clear the type cache less often (as seen with the removal of one of the calls to `TypeCache.clear()`). We still need to clear it when we use a placeholder type then replace it later with the final type and other dependent types need to be recalculated. I've added a check that the cached type matches what we compute. It triggered in this test case without the fix. It's currently not check-clang clean so it's not on by default for something like expensive checks builds. This change uncovered another issue where the LLVM types for an argument and its local temporary don't match. For example in type-cache-3, when expanding z::dc's argument into a temporary alloca, we ConvertType() the type of z::p which is `void ({}*)*`, which doesn't match the alloca GEP type of `{}*`. No noticeable compile time changes: https://llvm-compile-time-tracker.com/compare.php?from=3918dd6b8acf8c5886b9921138312d1c638b2937&to=50bdec9836ed40e38ece0657f3058e730adffc4c&stat=instructions Fixes #53465. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D118744 (cherry picked from commit 45084eab5e63550bf2fdbf325d8fa5498263130d)
* [clang][AVR] Implement standard calling convention for AVR and AVRTinyBen Shi2022-06-025-39/+263
| | | | | | | | | | | This patch implements avr-gcc's calling convention: https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D120720 (cherry picked from commit 51585aa240de6ef07979345de5406483d7393b7b)
* [PowerPC] Treat llvm.fmuladd intrinsic as using CTRQiu Chaofan2022-06-022-3/+137
| | | | | | | | | | | This fixes bug 55463, similar to D78668. This is a temporary fix since we will switch to post-isel CTR loop determination in the future. Reviewed By: dim, shchenz Differential Revision: https://reviews.llvm.org/D125746 (cherry picked from commit d9d15af7873fe16d7a0dde4def30f40fa9901777)
* Bump version to 14.0.5Tom Stellard2022-05-248-9/+9
|
* [CUDA][HIP] Externalize kernels with internal linkagellvmorg-14.0.4Yaxun (Sam) Liu2022-05-246-30/+91
| | | | | | | | | | | | | | | | | | | | | | This patch is a continuation of https://reviews.llvm.org/D123353. Not only kernels in anonymous namespace, but also template kernels with template arguments in anonymous namespace need to be externalized. To be more generic, this patch checks the linkage of a kernel assuming the kernel does not have __global__ attribute. If the linkage is internal then clang will externalize it. This patch also fixes the postfix for externalized symbol since nvptx does not allow '.' in symbol name. Reviewed by: Artem Belevich Differential Revision: https://reviews.llvm.org/D124189 Fixes: https://github.com/llvm/llvm-project/issues/54560 (cherry picked from commit 04fb81674ed7981397ffe70fe6a07b7168f6fe2f)
* [CUDA][HIP] Externalize kernels in anonymous name spaceYaxun (Sam) Liu2022-05-246-15/+43
| | | | | | | | | | | | | kernels in anonymous name space needs to have unique name to avoid duplicate symbols. Fixes: https://github.com/llvm/llvm-project/issues/54560 Reviewed by: Artem Belevich Differential Revision: https://reviews.llvm.org/D123353 (cherry picked from commit 4ea1d435099f992cc16127619b0feb64e070630d)
* AST: Move __va_list tag back to std conditionally on AArch64.Peter Collingbourne2022-05-245-139/+162
| | | | | | | | | | | | | | | | | | | | | In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode. To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *. Depends on D116773 Differential Revision: https://reviews.llvm.org/D116774
* AST: Make getEffectiveDeclContext() a member function of ↵Peter Collingbourne2022-05-241-78/+94
| | | | | | | | | | | | | ItaniumMangleContextImpl. NFCI. In an upcoming change we are going to need to access mangler state from the getEffectiveDeclContext() function. Therefore, make it a member function of ItaniumMangleContextImpl. Any callers that are not currently members of ItaniumMangleContextImpl or CXXNameMangler are made members of one or the other depending on where they are called from. Differential Revision: https://reviews.llvm.org/D116773
* [clang][NFC] Remove IgnoreLinkageSpecDeclsNathan Sidwell2022-05-241-14/+5
| | | | | | | | | | | | | | | The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec contexts. It doesn't do this consistently, but there is no need for it to do it at all. getEffectiveDeclContext never returns a linkage spec, as it either recurses, uses getRedeclContext (which itself removes the specs), or gets the decl context of non-namespace entities. This patch removes the function and all calls to it. For safety I add a couple of asserts to make sure we never get them. Reviewed By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D119748
* [clang][NFC] Standard substitution checking cleanupNathan Sidwell2022-05-241-41/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparing for module mangling changes I noticed some issues with the way we check for std::basic_string instantiations and friends. *) there's a single routine for std::basic_{i,o,io}stream but it is templatized on the length of the name. Really? just use a StringRef, rather than clone the entire routine just for 'basic_iostream'. *) We have a helper routine to check for char type, and call it from several places. But given all the instantiations are of the form TPL<char, Other<char> ...> we could just check the first arg is char and the later templated args are instantiating that same type. A simpler type comparison. *) Because basic_string has a third allocator parameter, it is open coded, which I found a little confusing. But otherwise it's exactly the same pattern as the iostream ones. Just tell that checker about whether there's an expected allocator argument.[*] *) We may as well return in each block of mangleStandardSubstitution once we determine it is not one of the entities of interest -- it certainly cannot be one of the other kinds of entities. FWIW this shaves about 500 bytes off the executable. [*] I suppose we could also have this routine a tri-value, with one to indicat 'it is this name, but it's not the one you're looking for', to avoid later calls trying different names? Reviewd By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D119333
* [AVR] Generate 'rcall' instead of 'call' on avr2 and avr25Ben Shi2022-05-242-31/+61
| | | | | | | | | | | | The 'call' (long call) instruction is available on avr3 and above, and devices in avr2 and avr25 should use the 'rcall' (short call) instruction for function calls. Reviewed By: aykevl, dylanmckay Differential Revision: https://reviews.llvm.org/D121539 (cherry picked from commit 45638931fb7c7a1b9c850e47601541b398868538)
* [AVR] Fix incorrect calling convention for varargs functionsBen Shi2022-05-244-3/+277
| | | | | | | | | | | | | An i8 argument should only cost 1 byte on the stack. This is compatible with avr-gcc. There are also more test cases (of calling convention) are added. Reviewed By: aykevl, dylanmckay Differential Revision: https://reviews.llvm.org/D121767 (cherry picked from commit 3fd9a320da8adbefa47071f70667d641f7dd26f2)
* [SystemZ] Bugfix for symbolic displacements.Jonas Paulsson2022-05-242-2/+12
| | | | | | | | | | | Properly handle the case where only the second operand of e.g. an MVC instruction uses a fixup for the displacement. Reviewed By: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D125982 (cherry picked from commit e547b04d5b2c20bb5d14e49a86837c77573b267a)
* [libc++][CI] added XFAIL LIBCXX-AIX-FIXME to new runnning test cases after ↵zhijian2022-05-2424-2/+23
| | | | | | | | | | | | | | | | | | install locale fileset on AIX OS. Summary: 1. there are 23 test cases which do not run because of locale fileset not install, after the locale installed, these test cases will be run and fail. "LIBCXX-AIX-FIXME" on the 23 test cases which remain to be investigated on AIX. 2.after installed the locale fileset , the test case libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp pass remove XFAIL: LIBCXX-AIX-FIXME from the file Reviewers: David Tenty Differential Revision: https://reviews.llvm.org/D124174 (cherry picked from commit bf4ddf18406c3e523c798ff7809f9e647580588c)
* [libc++] Always enable the ranges conceptsNikolas Klauser2022-05-248-14/+5
| | | | | | | | | The ranges concepts were already available in libc++13, so we shouldn't guard them with `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`. Fixes https://github.com/llvm/llvm-project/issues/54765 Differential Revision: https://reviews.llvm.org/D124011 (cherry picked from commit b177a90ce7b590dfce6479142f46fd1b9554a3b3)
* [ELF][ARM] Fix unneeded thunk for branches to hidden undefined weakFangrui Song2022-05-202-3/+13
| | | | | | Similar to D123750 for AArch64. (cherry picked from commit b483ce12281e31311efacf0047f95767517dcde9)
* Fix crash getting name of a template declTom Eccles2022-05-192-2/+17
| | | | | | | | | | | | | NamedDecl::getIdentifier can return a nullptr when DeclarationName::isIdentifier is false, which leads to a null pointer dereference when TypePrinter::printTemplateId calls ->getName(). NamedDecl::getName does the same thing in the successful case and returns an empty string in the failure case. This crash affects the llvm 14 packages on llvm.org. (cherry picked from commit 225b91e6cbba31ff1ce787a152a67977d08fdcab)
* [OpenMP] Fix library path missing when using OpenMPJoseph Huber2022-05-193-0/+20
| | | | | | | | | | | | | | | The changes in D122444 caused OpenMP programs built with the LLVM_ENABLE_RUNTIMES options to stop finding the libraries. We generally expect to link against the libraries associated with the clang installation itself but we no longer implicitly included that directory. This patch adds in the include path of the clang installations library to ensure we can find them. Reviewed By: jdoerfert, MaskRay Differential Revision: https://reviews.llvm.org/D122592 (cherry picked from commit fceea4e11028f4bfbafbd6893ddeb319420107d9)
* [ELF][AArch64] Fix unneeded thunk for branches to hidden undefined weakFangrui Song2022-05-193-4/+16
| | | | | | | | | | | | | | | | | | | | Similar to D119787 for PPC64. A hidden undefined weak may change its binding to local before some `isUndefinedWeak` code, so some `isUndefinedWeak` code needs to be changed to `isUndefined`. The undefined non-weak case has been errored, so just using `isUndefined` is fine. The Linux kernel recently has a usage that a branch from 0xffff800008491ee0 references a hidden undefined weak symbol `vfio_group_set_kvm`. It relies on the behavior that a branch to undefined weak resolving to the next instruction, otherwise it'd see spurious relocation out of range errors. Fixes https://github.com/ClangBuiltLinux/linux/issues/1624 Differential Revision: https://reviews.llvm.org/D123750 (cherry picked from commit 02eab52866775f1476028129d1b114235fddc127)
* [ELF] Ignore --no-add-neededFangrui Song2022-05-182-0/+2
| | | | | | | | | | | | | | It is used by a few projects like keepassxc and mumble. Also see https://bugzilla.redhat.com/show_bug.cgi?id=2070813 that Fedora gcc has an (unneeded) gcc12-no-add-needed.patch which adds --no-add-needed, although --[no-]add-needed has been deprecated in GNU ld since 2009. Adding this has low costs and makes several folks happy. This basically restores 8f13bef575c97db4d6c146c3bb647ac9e73a9248. Fixes https://github.com/llvm/llvm-project/issues/54756 (cherry picked from commit c29c19cb5327624dd31fcb776f8fbe66ca1011bb)
* [BOLT] Compact legacy profilesYi Kong2022-05-181-1/+18
| | | | | | | | | | Merging multiple legacy profiles (produced by instrumentation BOLT) can easily reach GiBs. Let merge-fdata compact the profiles during merge to significantly reduce space usage. Differential Revision: https://reviews.llvm.org/D123513 (cherry picked from commit 7d7771f34d14e0108adf02a6fd0b33943afae3da)
* [CodeGen] Use ABI alignment for C++ new expressionsDaniel Bertalan2022-05-182-1/+13
| | | | | | | | | | | | | | | | | | | | | | In case of placement new, if we do not know the alignment of the operand, we can't assume it has the preferred alignment. It might be e.g. a pointer to a struct member which follows ABI alignment rules. This makes UBSAN no longer report "constructor call on misaligned address" when constructing a double into a struct field of type double on i686. The psABI specifies an alignment of 4 bytes, but the preferred alignment used by Clang is 8 bytes. We now use ABI alignment for allocating new as well, as the preferred alignment should be used for over-aligning e.g. local variables, which isn't relevant for ABI code dealing with operator new. AFAICT there wouldn't be problems either way though. Fixes #54845. Differential Revision: https://reviews.llvm.org/D124736 (cherry picked from commit 93a8225da1f983cccb3e4b5e762369121aaa7dd5)
* [compiler-rt] Add NO_EXEC_STACK_DIRECTIVE on s390xTimm Bäder2022-05-181-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D125454 (cherry picked from commit 791e0d1bc85d1963abddb96cadcdf201c43a029f)
* [GlobalIsel] Fix fallback if stack protector isn't supported.Eli Friedman2022-05-182-1/+44
| | | | | | | | | | When GlobalISel fails, we need to report the error, and we need to set the FailedISel property. We skipped those steps if stack protector insertion failed, which led to a very strange miscompile. Differential Revision: https://reviews.llvm.org/D125584 (cherry picked from commit 96c2a0c9fff24803be14bfaa579e4f230763d3cc)
* [Driver][Solaris] -r: imply -nostdlib like GCCBrad Smith2022-05-182-4/+18
| | | | | | | | | | Similar to D116843 for Gnu.cpp Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D124356 (cherry picked from commit 3d7da810e4a6e1ade2c0d649f17f8aa820248765)
* [Driver][Ananas] -r: imply -nostdlib like GCCBrad Smith2022-05-182-5/+16
| | | | | | | | | | Similar to D116843 for Gnu.cpp Reviewed By: zhmu, MaskRay Differential Revision: https://reviews.llvm.org/D124729 (cherry picked from commit a132e527f25164268e08ebc63b043bbce8a043ed)
* [cmake] Increase -fms-compatibility-version in Windows toolchain fileShoaib Meenai2022-05-181-1/+1
| | | | | | Make it match LLVM's new minimum requirement (after https://reviews.llvm.org/D114639). (cherry picked from commit 4db89e23190d1d1590d88df08056d327e651c94c)
* [SystemZ] Bugfix in SystemZTargetLowering::combineINT_TO_FP()Jonas Paulsson2022-05-182-6/+43
| | | | | | | | | | | | | | | | | Make sure to also handle extended value types to avoid crashing. Resulting integers greater than 64 bits are not optimized (i128 is not a legal type), and vectorizing seems to result in libcalls instead of just scalarization. Other extended vector types like <10 x float> are however now handled and should result in vectorized conversions. Reviewed By: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D125881 (cherry picked from commit 4273e616e573f4854e9c659c2e6d8a31f3e3c595)
* [X86] combineX86ShuffleChain - don't fold to truncate(concat(V1,V2)) if it ↵Simon Pilgrim2022-05-182-1/+49
| | | | | | | | was already a PACK op Fixes #55050 (cherry picked from commit e8305c0b8f492272446d517e67d451f390d35dbe)
View Lorry Controller Status