- Jul 30, 2010
-
-
Nick Lewycky authored
llvm-svn: 109886
-
Nick Lewycky authored
getAdjustedAnalysisPointer. Part of a fix to PR7760. llvm-svn: 109883
-
Greg Clayton authored
Added "void Clear();" methods to SBDebugger, SBTarget and SBThread so they can release their shared pointers. llvm-svn: 109882
-
Bruno Cardoso Lopes authored
llvm-svn: 109881
-
Bob Wilson authored
beginning on ARM Darwin assembly files so that it won't be placed after debug sections. Radar 8252813. llvm-svn: 109879
-
Bruno Cardoso Lopes authored
declared during the addition of the assembler support, the additional changes are: - Add missing intrinsics - Move all SSE conversion instructions in X86InstInfo64.td to the SSE.td file. - Duplicate some patterns to AVX mode. - Step into PCMPEST/PCMPIST custom inserter and add AVX versions. llvm-svn: 109878
-
Bruno Cardoso Lopes authored
llvm-svn: 109877
-
Bob Wilson authored
llvm-svn: 109876
-
Daniel Dunbar authored
llvm-svn: 109875
-
Daniel Dunbar authored
llvm-svn: 109872
-
Sebastian Redl authored
llvm-svn: 109871
-
Peter Collingbourne authored
This patch introduces the ClassTemplateDecl::spec_{begin,end}() and FunctionTemplateDecl::{,partial_}spec_{begin,end}() member functions as a public interface for iterating over the declarations' specialisation sets. llvm-svn: 109870
-
Peter Collingbourne authored
This patch reimplements the find*Specialization family of member functions of {Class,Function}TemplateDecl in terms of a common implementation that uses SpecEntryTraits to obtain the most recent declaration. llvm-svn: 109869
-
Peter Collingbourne authored
SpecEntryTraits describes how to obtain the most recent declaration of a specialisation from an entry in a specialisation FoldingSet. llvm-svn: 109868
-
Sebastian Redl authored
llvm-svn: 109867
-
Fariborz Jahanian authored
auto-synthesized (nonfragile-abi2 specific). Fixes radar 8251648. llvm-svn: 109866
-
Abramo Bagnara authored
llvm-svn: 109865
-
Daniel Dunbar authored
llvm-svn: 109864
-
John Criswell authored
the llvm.memset() intrinsic family. No content changes. llvm-svn: 109863
-
Ted Kremenek authored
llvm-svn: 109862
-
Rafael Espindola authored
llvm-svn: 109859
-
Benjamin Kramer authored
llvm-svn: 109858
-
Argyrios Kyrtzidis authored
When we are deserializing the lexical decls of a DeclContext from PCH, notify the PCHReader to hold off passing Decls to the consumer until the DeclContext is fully prepared. Before, due to recursive loading, we could be in a situation where we would try to deserialize the decls of a DeclContext which was already doing that, and bad things would happen. In the specific case I encountered, the lexical decls would form a cycle and we would enter infinite loop territory. llvm-svn: 109857
-
Argyrios Kyrtzidis authored
-Replace CurrentlyLoadingTypeOrDecl with a counting scheme (NumCurrentElementsDeserializing) -Provide outside access to the mechanism by adding methods StartedDeserializing/FinishedDeserializing to ExternalASTSource. These are preparation for the next commit. llvm-svn: 109856
-
Eli Friedman authored
check the range of the constant when optimizing a comparison between a constant and a sign_extend_inreg node. llvm-svn: 109854
-
John McCall authored
(e.g. due to a broken template argument) following template parameters. Fixes rdar://problem/8254267 llvm-svn: 109853
-
Duncan Sands authored
llvm-svn: 109852
-
Duncan Sands authored
handles with a pointer to the containing map. When a map is copied, these pointers need to be corrected to point to the new map. If not, then consider the case of a map M1 which maps a value V to something. Create a copy M2 of M1. At this point there are two value handles on V, one representing V as a key in M1, the other representing V as a key in M2. But both value handles point to M1 as the containing map. Now delete V. The value handles remove themselves from their containing map (which destroys them), but only the first value handle is successful: the second one cannot remove itself from M1 as (once the first one has removed itself) there is nothing there to remove; it is therefore not destroyed. This causes an assertion failure "All references to V were not removed?". llvm-svn: 109851
-
John McCall authored
some downstream crashes, among them rdar://problem/8229840. llvm-svn: 109850
-
John McCall authored
an initializer requiring temporary object disposal. Fixes rdar:://problem/8246444. llvm-svn: 109849
-
Chris Lattner authored
The X86-64 ABI code didn't handle the case when a struct would get classified and turn up as "NoClass INTEGER" for example. This is perfectly possible when the first slot is all padding (e.g. due to empty base classes). In this situation, the first 8-byte doesn't take a register at all, only the second 8-byte does. This fixes this by enhancing the x86-64 abi stuff to allow and handle this case, reverts the broken fix for PR5831, and enhances the target independent stuff to be able to handle an argument value in registers being accessed at an offset from the memory value. This is the last x86-64 calling convention related miscompile that I'm aware of. llvm-svn: 109848
-
Daniel Dunbar authored
llvm-svn: 109847
-
Jim Grosbach authored
have 4 bits per register in the operand encoding), but have undefined behavior when the operand value is 13 or 15 (SP and PC, respectively). The trivial coalescer in linear scan sometimes will merge a copy from SP into a subsequent instruction which uses the copy, and if that instruction cannot legally reference SP, we get bad code such as: mls r0,r9,r0,sp instead of: mov r2, sp mls r0, r9, r0, r2 This patch adds a new register class for use by Thumb2 that excludes the problematic registers (SP and PC) and is used instead of GPR for those operands which cannot legally reference PC or SP. The trivial coalescer explicitly requires that the register class of the destination for the COPY instruction contain the source register for the COPY to be considered for coalescing. This prevents errant instructions like that above. PR7499 llvm-svn: 109842
-
-
-
Sebastian Redl authored
Make macro weirdness in chained PCH work. This required changing the way PCHReader and PCHWriter are initialized to correctly pick up all initializer. On the upside, this means that there is far less repetition in the dependent PCH now. llvm-svn: 109823
-
-
Gabor Greif authored
llvm-svn: 109821
-
Eric Christopher authored
llvm-svn: 109820
-
Benjamin Kramer authored
llvm-svn: 109818
-