- May 05, 2020
-
-
Vedant Kumar authored
Allow Language() to be called from const methods within UserExpression.
-
Jonas Devlieghere authored
Fix warning: ISO C++ requires the name after '::~' to be found in the same scope as the name before '::~' [-Wdtor-name]
-
Sanjay Patel authored
D79360 could change this kind of sequence.
-
Davide Italiano authored
Debug info generation & codegen now steps onto the correct line.
-
Stephen Neuendorffer authored
Previous patch broken flang, which has some yet-to-be resolved cyclic dependencies. This patch fixes the breakage by restricting the dependencies which are generated to public libraries, which is probably more sensible anyway. Differential Revision: https://reviews.llvm.org/D79366
-
Vedant Kumar authored
Summary: Languages can have different ways of formatting special characters. E.g. when debugging C++ code a string might look like "\b", but when debugging Swift code the same string would look like "\u{8}". To make this work, plugins override GetStringPrinterEscapingHelper. However, because there's a large amount of subtly divergent work done in each override, we end up with large amounts of duplicated code. And all the memory smashers fixed in one copy of the logic (see D73860) don't get fixed in the others. IMO the GetStringPrinterEscapingHelper is overly general and hard to use. I propose deleting it and replacing it with an EscapeStyle enum, which can be set as needed by each plugin. A fix for some swift-lldb memory smashers falls out fairly naturally from this deletion (https://github.com/apple/llvm-project/pull/1046). As the swift logic becomes really tiny, I propose moving it upstream as part of this change. I've added unit tests to cover it. rdar://61419673 Reviewers: JDevlieghere, davide Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D77843 -
Vedant Kumar authored
This reverts commit 88d9e432. Revert an accidental commit.
-
Vedant Kumar authored
Allow Language() to be called from const methods within UserExpression.
-
Vedant Kumar authored
Summary: Constrain which metadata nodes are allowed to be, or contain, DILocations. This ensures that logic for updating DILocations in a Module is complete. Currently, !llvm.loop metadata is the only odd duck which contains nested DILocations. This has caused problems in the past: some passes forgot to visit the nested locations, leading to subtly broken debug info and late verification failures. If there's a compelling reason for some future metadata to nest DILocations, we'll need to introduce a generic API for updating the locations attached to an Instruction before relaxing this check. Reviewers: aprantl, dsanders Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79245
-
shafik authored
The overloaded new operator in TestCppOperators.py are working by accident because of how we currently deal with artificial methods. Differential Revision: https://reviews.llvm.org/D79251
-
David Green authored
-
Dan Liew authored
It looks like some bots are failing with os log not giving any output. This might be due to the system under test being heavy load so the 2 minute window might not be large enough. This patch makes the window larger in the hope that this test will be more reliable. rdar://problem/62141527
-
Sander de Smalen authored
It seems this patch broke some buildbots, so reverting until I have had a chance to investigate. This reverts commit 6b90a688.
-
Erich Keane authored
There are some lookup oddities with these as reported in PR45780, and GCC doesn't support these behaviors at all. To be more consistent with GCC and prevent the crashes caused by our lookup issues, nip the problem in the bud and prohibit enums here.
-
Julian Lettner authored
abhinavgaba reported that that the custom-result-category.py test hangs on a Windows build bot [1]. Disable it for now. [1] https://reviews.llvm.org/D78164#2018178
-
Lang Hames authored
Also adds target_link_libraries. Thanks to @jcmac for spotting this.
-
Lang Hames authored
Thanks to @jcmac for pointing this out.
-
Stephen Neuendorffer authored
This reverts commit 4f0f4367. This seems to show some compile dependence problems, and also breaks flang.
-
Sander de Smalen authored
* svdupq builtins that duplicate scalars to every quadword of a vector are defined using builtins for svld1rq (load and replicate quadword). * svdupq builtins that duplicate boolean values to fill a predicate vector are defined using `svcmpne`. Reviewers: SjoerdMeijer, efriedma, ctetreau Reviewed By: efriedma Tags: #clang Differential Revision: https://reviews.llvm.org/D78750
-
Eli Friedman authored
If a varargs function is calling a non-varargs function, or vice versa, make sure we use the correct "varargs" bit for each. Fixes https://bugs.llvm.org/show_bug.cgi?id=45234 Differential Revision: https://reviews.llvm.org/D79199
-
Sanjay Patel authored
-
Snehasish Kumar authored
Today symbol names generated for machine basic block sections use a unary encoding to reduce bloat. This is essential when every basic block in the binary is assigned a symbol however with basic block clusters (rG05192e58) when we only need to generate a few non-temporary symbols we can assign more descriptive names making them more user friendly. With this change - Cold cluster section for function foo is named "foo.cold" Exception cluster section for function foo is named "foo.eh" Other cluster sections identified by their ids are named "foo.ID" Using this format works well with existing tools. It will demangle as expected and works with existing symbolizers, profilers and debuggers out of the box. $ c++filt _Z3foov.cold foo() [clone .cold] $ c++filt _Z3foov.eh foo() [clone .eh] $c++filt _Z3foov.1234 foo() [clone 1234] Tests for basicblock-sections are updated with some cleanup where appropriate. Differential Revision: https://reviews.llvm.org/D79221
-
peter klausler authored
Summary: Fix decimal formatting of 80-bit x87 values; the calculation ofnearest neighbor values failed to account for the explicitmost significant bit in that format. Replace MultiplyByRounded with MultiplyBy in binary->decimal conversions, since rounding won't happen and the name was misleading; then remove dead code, and migrate LoseLeastSignificantDigit() from one source file to another where it's still needed. Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby Reviewed By: tskeith Subscribers: llvm-commits, flang-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D79345
-
Fangrui Song authored
Fixes PR44357 For ARM ELF, regions covered by data mapping symbols `$d` are dumped as `.byte`, `.short` or `.word` but inline relocations are not printed. This patch merges its loop into the normal instruction printing loop so that inline relocations are printed. Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D79284
-
Sander de Smalen authored
This patch adds integer builtins for: - svaddv, svandv, sveorv, svmaxv, svminv, svorv. And FP builtins for: - svadda, svaddv, svmaxv, svmaxnmv, svminv, svminnmv
-
Valentin Churavy authored
- Exports MLIR targets to be used out-of-tree. - mimicks `add_clang_library` and `add_flang_library`. - Fixes libMLIR.so After https://reviews.llvm.org/D77515 libMLIR.so was no longer containing any object files. We originally had a cludge there that made it work with the static initalizers and when switchting away from that to the way the clang shlib does it, I noticed that MLIR doesn't create a `obj.{name}` target, and doesn't export it's targets to `lib/cmake/mlir`. This is due to MLIR using `add_llvm_library` under the hood, which adds the target to `llvmexports`. Differential Revision: https://reviews.llvm.org/D78773 [MLIR] Fix libMLIR.so and LLVM_LINK_LLVM_DYLIB Primarily, this patch moves all mlir references to LLVM libraries into either LLVM_LINK_COMPONENTS or LINK_COMPONENTS. This enables magic in the llvm cmake files to automatically replace reference to LLVM components with references to libLLVM.so when necessary. Among other things, this completes fixing libMLIR.so, which has been broken for some configurations since D77515. Unlike previously, the pattern is now that mlir libraries should almost always use add_mlir_library. Previously, some libraries still used add_llvm_library. However, this confuses the export of targets for use out of tree because libraries specified with add_llvm_library are exported by LLVM. Instead users which don't need/can't be linked into libMLIR.so can specify EXCLUDE_FROM_LIBMLIR A common error mode is linking with LLVM libraries outside of LINK_COMPONENTS. This almost always results in symbol confusion or multiply defined options in LLVM when the same object file is included as a static library and as part of libLLVM.so. To catch these errors more directly, there's now mlir_check_all_link_libraries. To simplify usage of add_mlir_library, we assume that all mlir libraries depend on LLVMSupport, so it's not necessary to separately specify it. tested with: BUILD_SHARED_LIBS=on, BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB, BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB + LLVM_LINK_LLVM_DYLIB. By: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Differential Revision: https://reviews.llvm.org/D79067 [MLIR] Move from using target_link_libraries to LINK_LIBS This allows us to correctly generate dependencies for derived targets, such as targets which are created for object libraries. By: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Differential Revision: https://reviews.llvm.org/D79243 Three commits have been squashed to avoid intermediate build breakage.
-
Siva Chandra Reddy authored
Reviewers: abrachet Differential Revision: https://reviews.llvm.org/D79185
-
Denys Petrov authored
-
Sean Fertile authored
-
David Green authored
-
Alexandre Ganea authored
Before this patch, global variables didn't have their namespace prepended in the Codeview debug symbol stream. This prevented Visual Studio from displaying them in the debugger (they appeared as 'unspecified error') Differential Revision: https://reviews.llvm.org/D79028
-
Louis Dionne authored
When building with modules, always enable local submodule visibility. It used to be disabled on Apple platforms, but it seems like we want to use the same flags on Apple and Linux now (see https://reviews.llvm.org/D74892).
-
Med Ismail Bennani authored
This patch fixes the test failure happening on Windows introduced by `01511741 `. Since the failure message comes from the OS, the test needs to support both UNIX and Windows messages. Signed-off-by:
Med Ismail Bennani <medismail.bennani@gmail.com>
-
Zarko authored
-
Zola Bridges authored
Summary: Moving these function initializations into separate functions makes it easier to read the runOnModule function. There is also precedent in the sanitizer code: asan has a function ModuleAddressSanitizer::initializeCallbacks(Module &M). I thought it made sense to break the initializations into two sets. One for the compiler runtime functions and one for the event callbacks. Tested with: check-all Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D79307
-
Louis Dionne authored
The double-braces were initially to escape Python string formatting, but that string isn't sent through Python string formatting.
-
Yaxun (Sam) Liu authored
We need a way to know supported targets by clang since people may use clang as assembler and they want to choose the clang which supports their target. This patch let clang print registered targets when --version option is passed to clang. Differential Revision: https://reviews.llvm.org/D79210
-
Louis Dionne authored
-
- May 04, 2020
-
-
Stanislav Mekhanoshin authored
This a hack to fix illegal 32 to 16 bit copies. The problem is when we make 16 bit subregs legal it creates a huge amount of failures which can only be resolved at once without a temporary hack like this. The next step is to change operands, instruction definitions and patterns until this hack is not needed. Differential Revision: https://reviews.llvm.org/D79119
-
Stephen Neuendorffer authored
In MLIR, it is common for automatically generated headers to be included in many places. To avoid tracking these dependencies explicitly in cmake, they are treated as part of a library which 'owns' the generated header. Users of the generated header link against the owning library. However, object libraries don't actually 'link', so this dependence gets lost. This patch adds an explicit dependence for these generated headers when creating object library targets to ensure that generated headers are appropriately generated Differential Revision: https://reviews.llvm.org/D79241
-