- Nov 15, 2013
-
-
Bob Wilson authored
This reverts commit 194701. Apple's bootstrapped LTO builds have been failing, and this change (along with compiler-rt 194702-194704) is the only thing on the blamelist. I will either reappy these changes or help debug the problem, depending on whether this fixes the buildbots. llvm-svn: 194780
-
Bob Wilson authored
Apple's bootstrapped LTO builds have been failing, and these changes (along with llvm 194701) are the only things on the blamelist. I will either reapply these changes or help debug the problem, depending on whether this fixes the buildbots. llvm-svn: 194779
-
Peter Zotov authored
llvm-svn: 194778
-
Rui Ueyama authored
We can add multiple undefined atoms having the same name to the symbol table. If such atoms are added, the symbol table compares their canBeNull attributes, and select one having a stronger constraint. If their canBeNulls are the same, the choice is arbitrary. Currently it choose the existing one. This patch changes the preference, so that the symbol table choose the new one if the new atom has a greater canBeNull or a fallback atom. This shouldn't change the behavior except the case described below. A new undefined atom may have a new fallback atom attribute. By choosing the new atom, we can update the fallback atom during Core Linking. PE/COFF actually need that. For example, _lseek is an alias for __lseek on Windows. One of an object file in OLDNAMES.LIB has an undefined atom for _lseek with the fallback to __lseek. When the linker tries to resolve _read, it supposed to read the file from OLDNAMES.LIB and use the new fallback from the file. Currently LLD cannot handle such case because duplicate undefined atoms with the same attributes are ignored. Differential Revision: http://llvm-reviews.chandlerc.com/D2161 llvm-svn: 194777
-
Rui Ueyama authored
llvm-svn: 194776
-
Richard Smith authored
until after we've referenced the operator; otherwise, we might pick up a not-yet-deduced type. llvm-svn: 194775
-
Peter Zotov authored
llvm-svn: 194774
-
Peter Zotov authored
This commit brings the module structure, argument order and primitive names in Llvm_target in order with the rest of the bindings, in preparation for adding TargetMachine API. llvm-svn: 194773
-
Peter Zotov authored
llvm-svn: 194772
-
Peter Zotov authored
LLVMGetTargetFromName used to compare two char* strings directly. llvm-svn: 194771
-
Peter Zotov authored
llvm-svn: 194770
-
Peter Zotov authored
LLVMGetTargetFromName was not yet present in an LLVM release, so this does not break compatibility. llvm-svn: 194769
-
Rui Ueyama authored
llvm-svn: 194768
-
Richard Smith authored
variable isn't really uninitialized, it's just not initialized yet. llvm-svn: 194767
-
Reed Kotler authored
short form. Constant islands will expand them if they are out of range. Since there is not direct object emitter at this time, it does not have any material affect because the assembler sorts this out. But we need to know for the actual constant island work. We track the difference by putting # 16 inst in the comments. llvm-svn: 194766
-
Matt Arsenault authored
Bitcasts between address spaces are no longer allowed. llvm-svn: 194765
-
Jordan Rose authored
This is similar to r194004: because we can't reason about the data structure invariants of std::basic_string, the analyzer decides it's possible for an allocator to be used to deallocate the string's inline storage. Just ignore this by walking up the stack, skipping past methods in classes with "allocator" in the name, and seeing if we reach std::basic_string that way. PR17866 llvm-svn: 194764
-
Jordan Rose authored
This has no effect on user-visible output, but can be used by post-processing tools that work with the generated HTML, rather than using CmpRuns.py's interface to work with plists. Patch by György Orbán! llvm-svn: 194763
-
Richard Smith authored
where we didn't. Extend our constant evaluation for __builtin_strlen to handle any constant array of chars, not just string literals, to match. llvm-svn: 194762
-
Eric Christopher authored
DbgVariable. No functional change. llvm-svn: 194761
-
Matt Arsenault authored
Patch by Michele Scandale! llvm-svn: 194760
-
Rui Ueyama authored
Including only Debug.h did not cause a compilation error, but you couldn't do anything (like writing something with <<) to raw_ostreams returned by llvm::dbgs() or llvm::errs() without including raw_ostream.h. So including it from Debug.h should make sense. Differential Revision: http://llvm-reviews.chandlerc.com/D2183 llvm-svn: 194759
-
Rui Ueyama authored
llvm-svn: 194757
-
Jason Molenda authored
do anything right now. Add a few new methods to the Thread base class which HistoryThread needs. I think I updated all the CMakeLists files correctly for the new plugin. llvm-svn: 194756
-
Tom Stellard authored
The LDS output queue is accessed via the OQAP register. The OQAP register cannot be live across clauses, so if value is written to the output queue, it must be retrieved before the end of the clause. With the machine scheduler, we cannot statisfy this constraint, because it lacks proper alias analysis and it will mark some LDS accesses as having a chain dependency on vertex fetches. Since vertex fetches require a new clauses, the dependency may end up spiltting OQAP uses and defs so the end up in different clauses. See the lds-output-queue.ll test for a more detailed explanation. To work around this issue, we now combine the LDS read and the OQAP copy into one instruction and expand it after register allocation. This patch also adds some checks to the EmitClauseMarker pass, so that it doesn't end a clause with a value still in the output queue and removes AR.X and OQAP handling from the scheduler (AR.X uses and defs were already being expanded post-RA, so the scheduler will never see them). Reviewed-by: Vincent Lejeune <vljn at ovi.com> llvm-svn: 194755
-
Rui Ueyama authored
llvm-svn: 194754
-
Chandler Carruth authored
subdirectories. The only thing needed here is to create the appropriate object file directories and add those as dependencies for the compilation rules. As a consequence, factor the non-source-file-specific dependencies for compilation rules into a helper variable. This fixes an issue where the project makefile wasn't actually a dependency of a bunch of compilation make rules for no apparant reason. This should have no observable effect for current makefile usage, but will simplify how we build other libraries and is something CMake already supports. llvm-svn: 194753
-
Tom Stellard authored
Patch by: Alex Deucher Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> llvm-svn: 194752
-
Tom Stellard authored
llvm-svn: 194751
-
Andrew Trick authored
This comes into play with patchpoint, which can fold multiple operands. Since the patchpoint is already treated as a call, the machine mem operands won't affect anything, and there's nothing to test. But we still want to do the right thing here to be sure that our MIs obey the rules. llvm-svn: 194750
-
Matt Arsenault authored
llvm-svn: 194749
-
Eric Christopher authored
llvm-svn: 194748
-
Hans Wennborg authored
This was casuing my release+asserts build on Windows to fail. llvm-svn: 194747
-
Rui Ueyama authored
llvm-svn: 194746
-
Joerg Sonnenberger authored
llvm-svn: 194745
-
- Nov 14, 2013
-
-
David Peixotto authored
llvm-svn: 194744
-
David Peixotto authored
This patch adds -I to the arguments that are passed to the integrated assembler from -Wa, and -Xassembler args. llvm-svn: 194743
-
Howard Hinnant authored
trivial in C++03, thus making it trivial in both C++03 and C++11. This patch allows one to opt-in/out of this decision with a macro. You can choose to have the pair copy constructor always be trivial, or always be non-trivial. The flag controlling this is now _LIBCPP_TRIVIAL_PAIR_COPY_CTOR. The client can define this flag to 1, and the pair copy constructor will be trivial (when possible of course), or to 0, and the pair copy constructor will be nontrivial. Default settings for this flag are set in <__config> (as usual). With this commit the default is _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 for all platforms except __APPLE__, which defaults to _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=0. llvm-svn: 194742
-
Hans Wennborg authored
They were previously not part of the install target. Differential Revision: http://llvm-reviews.chandlerc.com/D2154 llvm-svn: 194741
-
Richard Smith authored
template, that member has a dependent type (even if we can see the definition of the member of the primary template), because the array size could change in a member specialization. Patch by Karthik Bhat! llvm-svn: 194740
-