Release/11.x #288
Closed
Release/11.x #288
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
Add given input and mark it as tied. Doesn't create additional copy compared to matching input constraint to virtual register. Differential Revision: https://reviews.llvm.org/D85122 (cherry picked from commit d893278)
…her .debug_*) 0 tl;dr See D81784 for the 'tombstone value' concept. This patch changes our behavior to be almost the same as GNU ld (except that we also use 1 for .debug_loc): * .debug_ranges & .debug_loc: 1 (LLD<11: 0+addend; GNU ld uses 1 for .debug_ranges) * .debug_*: 0 (LLD<11: 0+addend; GNU ld uses 0; future LLD: -1) We make the tweaks because: 1) The new tombstone is novel and needs more time to be adopted by consumers before it's the default. 2) The old (gold) strategy had problems with zero-length functions - so rather than going back that, we're going to the GNU ld strategy which doesn't have that problem. 3) One slight tweak to (2) is to apply the .debug_ranges workaround to .debug_loc for the same reasons it applies to debug_ranges - to avoid terminating lists early. ----- http://lists.llvm.org/pipermail/llvm-dev/2020-July/143482.html The tombstone value -1 in .debug_line caused problems to lldb (fixed by D83957; will be included in 11.0.0) and breakpad (fixed by https://crrev.com/c/2321300). It may potentially affects other DWARF consumers. For .debug_ranges & .debug_loc: 1, an argument preferring 1 (GNU ld for .debug_ranges) over -2 is that: ``` {-1, -2} <<< base address selection entry {0, length} <<< address range ``` may create a situation where low_pc is greater than high_pc. So we use 1, the GNU ld behavior for .debug_ranges For other .debug_* sections, there haven't been many reports. One issue is that bloaty (src/dwarf.cc) can incorrectly count address ranges in .debug_ranges . To reduce similar disruption, this patch changes the tombstone values to be similar to GNU ld. This does mean another behavior change to the default trunk behavior. Sorry about it. The default trunk behavior will be similar to release/11.x while we work on a transition plan for LLD users. Reviewed By: dblaikie, echristo Differential Revision: https://reviews.llvm.org/D84825 (cherry picked from commit 004be40)
an array of unknown bound as the initializer of an array new expression. (cherry picked from commit bd08e0c)
The CFA is calculated as (SP/FP + offset), but when there are
SVE objects on the stack the SP offset is partly scalable and
should instead be expressed as the DWARF expression:
SP + offset + scalable_offset * VG
where VG is the Vector Granule register, containing the
number of 64bits 'granules' in a scalable vector.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D84043
(cherry picked from commit fd6584a)
This patch adds a CFI entry for each SVE callee saved register that needs unwind info at an offset from the CFA. The offset is a DWARF expression because the offset is partly scalable. The CFI entries only cover a subset of the SVE callee-saves and only encodes the lower 64-bits, thus implementing the lowest common denominator ABI. Existing unwinders may support VG but only restore the lower 64-bits. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D84044 (cherry picked from commit bb3344c)
This fixes an issue triggered by the following code, where emitEpilogue
got confused when trying to restore the SVE registers after the call,
whereas the call to bar() is implemented as a TCReturn:
int non_sve();
int sve(svint32_t x) { return non_sve(); }
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D84869
(cherry picked from commit f291663)
Fixed an incorrect pattern in lib/Target/AArch64/AArch64SVEInstrInfo.td for storing out <vscale x 2 x f32> unpacked scalable vectors. Added a couple of tests to test/CodeGen/AArch64/sve-st1-addressing-mode-reg-imm.ll Differential Revision: https://reviews.llvm.org/D85441 (cherry picked from commit 0905d9f)
Introduced by fd6584a Following similar use of casts in AsmParser.cpp, for instance - ideally this type would use unsigned chars as they're more representative of raw data and don't get confused around implementation defined choices of char's signedness, but this is what it is & the signed/unsigned conversions are (so far as I understand) safe/bit preserving in this usage and what's intended, given the API design here. (cherry picked from commit e31cfc4)
By Tobias Hieta!
The code wasn't taking into account that the two operands passed to ptest could be identical and was trying to erase them twice. Differential Revision: https://reviews.llvm.org/D85892 (cherry picked from commit 6c7957c)
Reviewed By: lkail Differential Revision: https://reviews.llvm.org/D85659 (cherry picked from commit 4d52ebb)
…d through to F18_FC fixes BUG 46307 Differential Revision: https://reviews.llvm.org/D84266 (cherry picked from commit 4a4cafa)
When the f18 frontend calls the link editor, put the libraries and object files in the correct order. Fixes the issues reported here flang-compiler/flang#897 Reviewed By: sscalpone, AlexisPerry Differential Revision: https://reviews.llvm.org/D84340 (cherry picked from commit ca0bf44)
When flang is invoked with no files it waits for input on stdin. Make it print a message saying this to prevent the user being surprised. Differential Revision: https://reviews.llvm.org/D84855 (cherry picked from commit dd5ea56)
Add a usage string and a defaults section that clarifies: * If no input files are given, f18 reads from stdin * If no input files are given, f18 dumps the parse tree. * The default behaviour is to exec F18_FC. * The fefault F18_FC setting is 'gfortran' Adds a simple regression test which tests the top and tail of the help screen and the exit status. Depends on D84855 Differential Revision: https://reviews.llvm.org/D84856 (cherry picked from commit b068d19)
As expected by user in http://lists.llvm.org/pipermail/flang-dev/2020-June/000404.html Depends on D84856 Differential Revision: https://reviews.llvm.org/D84857 (cherry picked from commit 30e45f3)
Fixed some version information in flang/f18: - fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017) - added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose Reviewed By: sscalpone, AlexisPerry, richard.barton.arm, tskeith Differential Revision: https://reviews.llvm.org/D84334 (cherry picked from commit 89a9db4)
…tion Clang command line docs mention `-fno-stack-clash-protection`, and GCC also uses -fno-stack-clash-protection. Fixes PR47139 Reviewed By: tstellar Differential Revision: https://reviews.llvm.org/D85844 (cherry picked from commit df3bfaa)
…< C (PR47133) While x*undef is undef, shift-by-undef is poison, which we must avoid introducing. Also log2(iN undef) is *NOT* iN undef, because log2(iN undef) u< N. See https://bugs.llvm.org/show_bug.cgi?id=47133 (cherry picked from commit 12d93a2)
…n initFeatureMap. Properly set "simd128" in the feature map when "unimplemented-simd128" is requested. initFeatureMap is used to create the feature vector used by handleTargetFeatures. There are later calls to initFeatureMap in CodeGen that were using these flags to recreate the map. But the original feature vector should be passed to those calls. So that should be enough to rebuild the map. The only issue seemed to be that simd128 was not enabled in the map by the first call to initFeatureMap. Using the SIMDLevel set by handleTargetFeatures in the later calls allowed simd128 to be set in the later versions of the map. To fix this I've added an override of setFeatureEnabled that will update the map the first time with the correct simd dependency. Differential Revision: https://reviews.llvm.org/D85806 (cherry picked from commit 2b8ad6b)
We can use this to remove some calls to initFeatureMap from Sema and CodeGen when a function doesn't have a target attribute. This reduces compile time of the linux kernel where this map is needed to diagnose some inline assembly constraints based on whether sse, avx, or avx512 is enabled. Differential Revision: https://reviews.llvm.org/D85807 (cherry picked from commit 5c1fe4e)
… after D83273 Previously the time complexity is O(|number of paths from the root to an implied feature| * CPU_FWATURE_MAX) where CPU_FEATURE_MAX is 92. The number of paths can be large (theoretically exponential). For an inline asm statement, there is a code path `clang::Parser::ParseAsmStatement -> clang::Sema::ActOnGCCAsmStmt -> ASTContext::getFunctionFeatureMap` leading to potentially many calls of getImpliedEnabledFeatures (41 for my -march=native case). We should improve the performance a bit in case the number of inline asm statements is large (Linux kernel builds). Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D85257 (cherry picked from commit 0c7af8c)
Otherwise, lots of these tests fail with a CHECK error similar to: ==12345==AddressSanitizer CHECK failed: compiler-rt/lib/asan/asan_posix.cpp:120 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e) This is because the default pthread stubs in FreeBSD's libc always return failures (such as ENOSYS for pthread_key_create) in case the pthread library is not linked in. Reviewed By: arichardson Differential Revision: https://reviews.llvm.org/D85082 (cherry picked from commit 3aecf4b)
(cherry picked from commit cd5ab56)
(cherry picked from commit 92e82a2)
(cherry picked from commit 44613bb)
This reverts commit 844f018.
We unconditionally marked i64 as Custom, but did not install a handler in ReplaceNodeResults when i64 isn't legal type. This leads to ReplaceNodeResults asserting. We have two options to fix this. Only mark i64 as Custom on 64-bit targets and let it expand to two i32 bitreverses which each need a VPPERM. Or the other option is to add the Custom handling to ReplaceNodeResults. This is what I went with. (cherry picked from commit 57c0c4a)
…ate instantiation They can get stale at use time because of updates from other recursive specializations. Instead, rely on the existence of previous declarations to add the specialization. Differential Revision: https://reviews.llvm.org/D87853 (cherry picked from commit cffb0dd) This is a re-commit of 8ac7095 with some modifications to avoid changing the clang API.
The non-strict variants are already handled because they are canonicalized to strict variants by swapping hands in both the select and icmp, and the fold simply considers that strictness is irrelevant here. But that isn't actually true for the last pattern, as PR48390 reports. (cherry picked from commit f16320b)
… strict comparison (PR48390) We could create uadd.sat under incorrect circumstances if a select with -1 as the false value was canonicalized by swapping the T/F values. Unlike the other transforms in the same function, it is not invariant to equality. Some alive proofs: https://alive2.llvm.org/ce/z/emmKKL Based on original patch by David Green! Fixes https://bugs.llvm.org/show_bug.cgi?id=48390 Differential Revision: https://reviews.llvm.org/D92717 (cherry picked from commit e6f2a79)
GlobalAlias::getAliasee() may not always point directly to a GlobalVariable. In such cases, try to find the canonical GlobalVariable that the alias refers to. Link: ClangBuiltLinux/linux#1208 Reviewed By: dvyukov, nickdesaulniers Differential Revision: https://reviews.llvm.org/D92846 (cherry picked from commit c28b18a)
D73999 / commit 75af9da added for LLVM 11 a check that sh_flags and sh_entsize (and sh_type) changes are an error, in line with GNU assembler. However, GNU assembler accepts and GCC generates an abbreviated form: while the first .section contains the flags and entsize, subsequent sections simply contain the name without repeating entsize or flags. Do likewise for better compatibility. See https://bugs.llvm.org/show_bug.cgi?id=48201 Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D92052 (cherry picked from commit 1deff40)
As reported in PR48177, the type-deduction extraction ends up going into an infinite loop when the type referred to has a recursive definition. This stops recursing and just substitutes the type-source-info the TypeLocBuilder identified when transforming the base. (cherry picked from commit 1c98f98)
Instead of relying on whether a certain identifier is a builtin, introduce BuiltinAttr to specify a declaration as having builtin semantics. This fixes incompatible redeclarations of builtins, as reverting the identifier as being builtin due to one incompatible redeclaration would have broken rest of the builtin calls. Mostly-compatible redeclarations of builtins also no longer have builtin semantics. They don't call the builtin nor inherit their attributes. A long-standing FIXME regarding builtins inside a namespace enclosed in extern "C" not being recognized is also addressed. Due to the more correct handling attributes for builtin functions are added in more places, resulting in more useful warnings. Tests are updated to reflect that. Intrinsics without an inline definition in intrin.h had `inline` and `static` removed as they had no effect and caused them to no longer be recognized as builtins otherwise. A pthread_create() related test is XFAIL-ed, as it relied on it being recognized as a builtin based on its name. The builtin declaration syntax is too restrictive and doesn't allow custom structs, function pointers, etc. It seems to be the only case and fixing this would require reworking the current builtin syntax, so this seems acceptable. Fixes PR45410. Reviewed By: rsmith, yutsumi Differential Revision: https://reviews.llvm.org/D77491
…bility objc_super is special and needs LookupPredefedObjCSuperType() called before performing builtin type comparisons. This fixes an error when compiling macOS headers. A test is added. Differential Revision: https://reviews.llvm.org/D87917
…red yet. This happens in glibc's headers. It's important that we recognize these functions so that we can mark them as returns_twice. Differential Revision: https://reviews.llvm.org/D88518
We now recognize this function as a builtin despite it having an unexpected number of parameters; make sure we don't enforce that it has only 1 argument for its 2 parameters.
…alue check in realPathFromHandle() `GetFinalPathNameByHandleW(,,N,)` returns: - `< N` on success (this value does not include the size of the terminating null character) - `>= N` if buffer is too small (this value includes the size of the terminating null character) So, when `N == Buffer.capacity() - 1`, we need to resize buffer if return value is > `Buffer.capacity() - 2`. Also, we can set `N` to `Buffer.capacity()`. Thus, without this patch `realPathFromHandle()` returns unfilled buffer when length of the final path of the file is equal to `Buffer.capacity()` or `Buffer.capacity() - 1`. Reviewed By: andrewng, amccarth Differential Revision: https://reviews.llvm.org/D86564 (cherry picked from commit ceffd69)
…e doesn't reside on a local drive On Windows, after commit 881ba10, tools using TempFile would error with "bad file descriptor" when writing the file on a network drive. It appears that setting the delete-on-close bit via SetFileInformationByHandle/FileDispositionInfo prevented it from accessing the file on network drives, and although using FILE_DISPOSITION_INFO seems to work, it causes other troubles. Differential Revision: https://reviews.llvm.org/D81803 (cherry picked from commit 79657e2)
…t-extended register offsets. The G_ZEXT in these cases seems to actually come from a combine that we do but SelectionDAG doesn't. Looking through it allows us to match "uxtw #2" addressing modes. Differential Revision: https://reviews.llvm.org/D91475 (cherry picked from commit 0b60906)
When we have a 128-bit register, emitTestBit would incorrectly narrow to 32 bits always. If the bit number was > 32, then we would need a TB(N)ZX. This would cause a crash, as we'd have the wrong register class. (PR48379) This generalizes `narrowExtReg` into `moveScalarRegClass`. This also allows us to remove `widenGPRBankRegIfNeeded` entirely, since `selectCopy` correctly handles SUBREG_TO_REG etc. This does create some codegen changes (since `selectCopy` uses the `all` regclass variants). However, I think that these will likely be optimized away, and we can always improve the `selectCopy` code. It looks like we should revisit `selectCopy` at this point, and possibly refactor it into at least one `emit` function. Differential Revision: https://reviews.llvm.org/D92707 (cherry picked from commit 195a7af)
Although the DWARF specification states that .debug_aranges entries can't have length zero, these can occur in the wild. There's no particular reason to enforce this part of the spec, since functionally they have no impact. The patch removes the error and introduces a new warning for premature terminator entries which does not stop parsing. This is a relanding of cb3a598, adding the missing obj2yaml part that was needed. Fixes https://bugs.llvm.org/show_bug.cgi?id=46805. See also https://reviews.llvm.org/D71932 which originally introduced the error. Reviewed by: ikudrin, dblaikie, Higuoxing Differential Revision: https://reviews.llvm.org/D85313
Set the return variable to "" in find_first_existing_vc_file to say that there is a repository, but no file to depend on. This works transparently for all other callers that handle undefinedness and equality to an empty string the same way. Use the knowledge to avoid depending on __FakeVCSRevision.h if there is no git repository at all (for example when building a release) as there is no point in regenerating an empty VCSRevision.h. Differential Revision: https://reviews.llvm.org/D92718 (cherry picked from commit 6e890ec)
…ift s32->s64 custom legalization. Almost NFC, except it catches more cases and gives a 0.1% CTMark -O0 size win.
…s64. This was supposed to be done in the first place as is currently the case for G_ASHR and G_LSHR but was forgotten when the original shift legalization overhaul was done last year. This was exposed because we started falling back on s32 = s32, s64 SHLs due to a recent combiner change. Gives a very minor (0.1%) code size -O0 improvement on consumer-typeset.
Revert values in CXCursorKind as they were before CXCursor_CXXAddrspaceCastExpr was introduced in a6a237f ([OpenCL] Added addrspace_cast operator in C++ mode., 2020-05-18). Insert CXCursor_CXXAddrspaceCastExpr after the last expression in CXCursorKind using the next available value. Reviewed By: akyrtzi, svenvh Differential Revision: https://reviews.llvm.org/D90385 (cherry picked from commit bbdbd02)
|
This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. |
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
Closes llvm#288 The action mirrors https://github.com/llvm/llvm-project/blob/main/.github/workflows/clang-tests.yml with a few minor differences: - it is not restricted to: `github.repository_owner == 'llvm'` - it triggers on pull requests and pushes to `main` instead of `release` branches I suggest adding branch protection rule to require tests to pass for each pull request: `Settings -> Branches -> Add branch protection rule -> Require status checks to pass before merging`
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this pull request
Jul 17, 2024
Closes llvm#288 The action mirrors https://github.com/llvm/llvm-project/blob/main/.github/workflows/clang-tests.yml with a few minor differences: - it is not restricted to: `github.repository_owner == 'llvm'` - it triggers on pull requests and pushes to `main` instead of `release` branches I suggest adding branch protection rule to require tests to pass for each pull request: `Settings -> Branches -> Add branch protection rule -> Require status checks to pass before merging`
keryell
pushed a commit
to keryell/llvm-project
that referenced
this pull request
Oct 19, 2024
Closes llvm#288 The action mirrors https://github.com/llvm/llvm-project/blob/main/.github/workflows/clang-tests.yml with a few minor differences: - it is not restricted to: `github.repository_owner == 'llvm'` - it triggers on pull requests and pushes to `main` instead of `release` branches I suggest adding branch protection rule to require tests to pass for each pull request: `Settings -> Branches -> Add branch protection rule -> Require status checks to pass before merging`
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
small fixes + improve readability from llvm 11.x branch