- Sep 05, 2015
-
-
Andrew Wilkins authored
Summary: This diff attempts to address the concerns raised in http://reviews.llvm.org/D12488. We introduce a new USE_SHARED option to llvm_config, which, if set, causes the target to be linked against libLLVM. add_llvm_utility now uniformly disables linking against libLLVM. These utilities are not intended for distribution, and this keeps the option handling more centralised. llvm-shlib is now processes before any other "tools" subdirectories, ensuring the libLLVM target is defined before its dependents. One main difference from what was requested: llvm_config does not prune LLVM_DYLIB_COMPONENTS from the components passed into explicit_llvm_config. This is because the "all" component does something special, adding additional libraries (namely libLTO). Adding the component libraries after libLLVM should not be a problem, as symbols will be resolved in libLLVM first. Finally, I'm not really happy with the DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a better way to get the following: - link all tools and shared libraries to libLLVM if LLVM_LINK_LLVM_DYLIB is set - some way of explicitly *not* doing so for utilities and libLLVM itself Suggestions for improvement here are particularly welcome. Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12590 llvm-svn: 246918
-
Tobias Grosser authored
Originally, we disallowed the import of multi-dimensional access functions due to our code generation not supporting the generation of new address expressions for multi-dimensional memory accesses. When building our run-time alias check infrastructure we added code generation support for multi-dimensional address calculations. Hence, we can now savely allow the import of new multi-dimensional access functions. llvm-svn: 246917
-
Tobias Grosser authored
llvm-svn: 246916
-
Eric Fiselier authored
llvm-svn: 246915
-
Eric Fiselier authored
llvm-svn: 246914
-
Eric Fiselier authored
llvm-svn: 246913
-
Tanya Lattner authored
llvm-svn: 246912
-
Tanya Lattner authored
llvm-svn: 246911
-
Eric Fiselier authored
llvm-svn: 246910
-
Eric Fiselier authored
llvm-svn: 246909
-
Craig Topper authored
llvm-svn: 246908
-
Eric Fiselier authored
llvm-svn: 246906
-
NAKAMURA Takumi authored
We want a deterministic output. GNU AS leaves it zero. FIXME: It may be optional by its user, like llc and clang. llvm-svn: 246905
-
Davide Italiano authored
This commit accomplish two goals: 1) it's a step forward to deprecate macho-dump, now less than 40 tests rely on it. 2) It tests all the MachO specific features introduced in llvm-readobj in the following commits: r246789, r246665, r246474. While the conversion is mostly mechanical (I double-checked all the tests output one by one, but still), a post-commit review is greatly appreciated. llvm-svn: 246904
-
Andrew Kaylor authored
llvm-svn: 246903
-
Michael J. Spencer authored
It wasn't obvious what the assembly was to generate these relocations, so I did the test with yaml. llvm-svn: 246902
-
Michael J. Spencer authored
[elf2] Correctly handle sections with an alignment of 0. Spec says to treat it as an alignment of 1. llvm-svn: 246901
-
Hal Finkel authored
PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from an input pattern that looks like this: and(or(x, c1), c2) but the associated logic does not work if there are bits that are 1 in c1 but 0 in c2 (these are normally canonicalized away, but that can't happen if the 'or' has other users. Make sure we abort the transformation if such bits are discovered. Fixes PR24704. llvm-svn: 246900
-
Andrew Kaylor authored
llvm-svn: 246899
-
Evgeniy Stepanov authored
The variable is actually called ANDROID_SERIAL. This was not exercised on the bots until today. Should fix the sanitizer-x86_64-linux failures. llvm-svn: 246898
-
Andrew Kaylor authored
llvm-svn: 246897
-
Andrew Kaylor authored
Differential Revision: http://reviews.llvm.org/D12434 llvm-svn: 246896
-
Eric Fiselier authored
llvm-svn: 246895
-
Siva Chandra authored
Reviewers: chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12653 llvm-svn: 246894
-
Eric Fiselier authored
llvm-svn: 246893
-
Michael J. Spencer authored
llvm-svn: 246892
-
Evgeniy Stepanov authored
Tests need to be run either via asanwrapper or asanwrapper64 depending in the binary bitness. This matters when testing on an aarch64 device. llvm-svn: 246891
-
George Burgess IV authored
Apparently there are many cast kinds that may cause implicit pointer arithmetic to happen. In light of this, the cast ignoring logic introduced in r246877 has been changed to only ignore a small set of cast kinds, and a test for this behavior has been added. Thanks to Richard for catching this before it became a bug report. :) llvm-svn: 246890
-
Reid Kleckner authored
llvm-svn: 246889
-
Kostya Serebryany authored
llvm-svn: 246888
-
Greg Clayton authored
llvm-svn: 246887
-
Michael J. Spencer authored
llvm-svn: 246886
-
Siva Chandra authored
Summary: lldb::tid_t is 64 bit, but "long" need not always be 64 bit. Reviewers: chying, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12650 llvm-svn: 246885
-
Enrico Granata authored
Add a --language (-l) option to type category {enable|disable} to allow people to turn on and off formatters for a given language llvm-svn: 246884
-
- Sep 04, 2015
-
-
Hal Finkel authored
We were crashing in CodeGen given input like this: int self_alias(void) __attribute__((weak, alias("self_alias"))); such a self-alias is invalid, but instead of diagnosing the situation, we'd proceed to produce IR for both the function declaration and the alias. Because we already had a function named 'self_alias', the alias could not be named the same thing, and so LLVM would pick a different name ('self_alias1' for example) for that value. When we later called CodeGenModule::checkAliases, we'd look up the IR value corresponding to the alias name, find the function declaration instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent this is simply to avoid creating the wrongly-named alias value in the first place and issue the diagnostic there (instead of in checkAliases). We detect a related cycle case in CodeGenModule::EmitAliasDefinition already, so this just adds a second such check. Even though the other test cases for this 'alias definition is part of a cycle' diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression test for this case. This is because I can't add this check to test/Sema/attr-alias-elf.c without disturbing the other test cases in that file. In order to avoid construction of the bad IR values, this diagnostic is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant declaration is not added to the Aliases vector). The other cycle checks are done within the CodeGenModule::checkAliases function based on the Aliases vector, called from CodeGenModule::Release. However, if there have been errors earlier, HandleTranslationUnit does not call Release, and so checkAliases is never called, and so none of the other diagnostics would be produced. Fixes PR23509. llvm-svn: 246882
-
Richard Smith authored
directory, and our frontend action cares whether the frontend setup actually succeeded. llvm-svn: 246881
-
Reid Kleckner authored
This fixes an issue raised in D12412, where we generated invalid IR. Thanks to Vedant Kumar for coming up with the initial work around. Differential Revision: http://reviews.llvm.org/D12412 llvm-svn: 246880
-
Angel Garcia Gomez authored
Summary: The InitListExpr subtree is visited twice, this caused the check to do multiple replacements. Added a set to avoid it. Reviewers: klimek, alexfh Subscribers: cfe-commits, alexfh Differential Revision: http://reviews.llvm.org/D12631 llvm-svn: 246879
-
Rui Ueyama authored
Identical COMDAT Folding is a feature to merge COMDAT sections by contents. Two sections are considered the same if their contents, relocations, attributes, etc, are all the same. An interesting fact is that MSVC linker takes "iterations" parameter for ICF because the algorithm they are using is iterative. Merging two sections could make more sections to be mergeable because different relocations could now point to the same section. ICF is repeated until we get a convergence (until no section can be merged). This algorithm is not fast. Usually it needs three iterations until a convergence is obtained. In the new algorithm implemented in this patch, we consider sections and relocations as a directed acyclic graph, and we try to merge sections whose outdegree is zero. Sections with outdegree zero are then removed from the graph, which makes other sections to have outdegree zero. We repeat that until all sections are processed. In this algorithm, we don't iterate over the same sections many times. There's an apparent issue in the algorithm -- the section graph is not guaranteed to be acyclic. It's actually pretty often cyclic. So this algorithm cannot eliminate all possible duplicates. That's OK for now because the previous algorithm was not able to eliminate cycles too. I'll address the issue in a follow-up patch. llvm-svn: 246878
-
George Burgess IV authored
Improvements: - For all types, we would give up in a case such as: __builtin_object_size((char*)&foo, N); even if we could provide an answer to __builtin_object_size(&foo, N); We now provide the same answer for both of the above examples in all cases. - For type=1|3, we now support subobjects with unknown bases, as long as the designator is valid. Thanks to Richard Smith for the review + design planning. Review: http://reviews.llvm.org/D12169 llvm-svn: 246877
-