- Aug 21, 2012
-
-
Kostya Serebryany authored
llvm-svn: 162258
-
Craig Topper authored
llvm-svn: 162257
-
Michael Liao authored
llvm-svn: 162256
-
Richard Smith authored
llvm-svn: 162255
-
John McCall authored
to overwrite objects that might have been allocated into the type's tail padding. This patch is missing some potential optimizations where the destination is provably a complete object, but it's necessary for correctness. Patch by Jonathan Sauer. llvm-svn: 162254
-
Richard Smith authored
if a diagnostic is emitted outside of any source file. The fix mirrors the corresponding code in TextDiagnosticPrinter. This required moving the functional parts of SDiagRenderer into SDiagWriter so they can be reused in the non-rendering codepath. No functionality change. llvm-svn: 162253
-
John McCall authored
diagnostics for bad deployment targets and adding a few more predicates. Includes a patch by Jonathan Schleifer to enable ARC for ObjFW. llvm-svn: 162252
-
Dmitri Gribenko authored
llvm-svn: 162251
-
Jim Ingham authored
SBValue::GetTypeName and SBValue::GetByteSize might have to update the dynamic value - which might involve running code. So they need to take the stop lock & target locks. <rdar://problem/12001204> llvm-svn: 162250
-
Jack Carter authored
just trying to show it did not crash and burn. This patch checks that the resultant .ll contents are correct. llvm-svn: 162249
-
Sam Panzer authored
The old error message stating that 'begin' was an undeclared identifier is replaced with a new message explaining that the error is in the range expression, along with which of the begin() and end() functions was problematic if relevant. Additionally, if the range was a pointer type or defines operator*, attempt to dereference the range, and offer a FixIt if the modified range works. llvm-svn: 162248
-
Jakob Stoklund Olesen authored
*** Bad machine code: Explicit definition marked as use *** - function: test_cos - basic block: BB#0 L.entry (0x7ff2a2024fd0) - instruction: VSETLNi32 %D11, %D11<undef>, %R0, 0, pred:14, pred:%noreg, %Q5<imp-use,kill>, %Q5<imp-def> - operand 0: %D11 llvm-svn: 162247
-
Jordan Rose authored
By doing this in the constraint managers, we can ensure that ANY reference whose value we don't know gets the effect, even if it's not a top-level parameter. llvm-svn: 162246
-
Dmitri Gribenko authored
Add a flag PrintingPolicy::DontRecurseInDeclContext to provide "terse" output from DeclPrinter. The motivation is to use DeclPrinter to print declarations in user-friendly format, without overwhelming user with inner detail of the declaration being printed. Also add many tests for DeclPrinter. There are quite a few things that we print incorrectly: search for WRONG in DeclPrinterTest.cpp -- and these tests check our output against incorrect output, so that we can fix/refactor/rewrite the DeclPrinter later. llvm-svn: 162245
-
John McCall authored
First, when synthesizing an explicitly strong/retain/copy property of Class type, don't pretend during compatibility checking that the property is actually assign. Instead, resolve incompatibilities by secretly changing the type of *implicitly* __unsafe_unretained Class ivars to be strong. This is moderately evil but better than what we were doing. Second, when synthesizing the setter for a strong property of non-retainable type, be sure to use objc_setProperty. This is possible when the property is decorated with the NSObject attribute. This is an ugly, ugly corner of the language, and we probably ought to deprecate it. The first is rdar://problem/12039404; the second was noticed by inspection while fixing the first. llvm-svn: 162244
-
Eric Christopher authored
Author: Eric Christopher <echristo@apple.com> Date: Thu Aug 16 23:50:46 2012 +0000 Add some caching here for the builtin types. rdar://12117935 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162066 91177308-0d34-0410-b5e6-96231b3b80d8 after fixing a thinko. llvm-svn: 162243
-
Johnny Chen authored
llvm-svn: 162239
-
Dmitri Gribenko authored
does not return true for all implicit decls currently. This should fix PR13634 for now, but Decl::isImplicit() should be fixed, too. llvm-svn: 162238
-
David Blaikie authored
llvm-svn: 162236
-
David Blaikie authored
llvm-svn: 162235
-
Jordan Rose authored
Under GC, a release message is ignored, so "release and stop tracking" just becomes "stop tracking". But CFRelease is still honored. This is the main difference between ns_consumed and cf_consumed. llvm-svn: 162234
-
Jakob Stoklund Olesen authored
The getSumForBlock function was quadratic in the number of successors because getSuccWeight would perform a linear search for an already known iterator. This patch was originally committed as r161460, but reverted again because of assertion failures. Now that duplicate Machine CFG edges have been eliminated, this works properly. llvm-svn: 162233
-
- Aug 20, 2012
-
-
Jordan Rose authored
This should unbreak the buildbots (r162220). llvm-svn: 162232
-
Michael J. Spencer authored
llvm-svn: 162231
-
Jakob Stoklund Olesen authored
IR that hasn't been through SimplifyCFG can look like this: br i1 %b, label %r, label %r Make sure we don't create duplicate Machine CFG edges in this case. Fix the machine code verifier to accept conditional branches with a single CFG edge. llvm-svn: 162230
-
DeLesley Hutchins authored
ICE in friend functions. llvm-svn: 162229
-
Johnny Chen authored
Also modify the boundary condition test case SBDebugger.DispatchInput(None) to be wrapped inside a try-except clause for now. llvm-svn: 162228
-
Jakob Stoklund Olesen authored
LLVM IR has labeled duplicate CFG edges, but since Machine CFG edges don't have labels, it doesn't make sense to allow duplicates. There is no way of telling what the edges mean. Duplicate CFG edges cause confusion when dealing with edge weights. It seems that code producing duplicate CFG edges usually does the wrong thing with edge weights. llvm-svn: 162227
-
Eli Friedman authored
llvm-svn: 162226
-
Manuel Klimek authored
of matchers, categorized by type and fully expanded for the context in which they can be used. I used a script to generate this documentation which I'll want to be scrunitized by a code review before checking it in. llvm-svn: 162225
-
Jakob Stoklund Olesen authored
This pass often has weird CFG hacks and hand-written MI building code that can go wrong in many ways. llvm-svn: 162224
-
Jakob Stoklund Olesen authored
Verify that the predecessor and successor lists are consistent and free of duplicates. llvm-svn: 162223
-
Jakob Stoklund Olesen authored
The test case ARM/2011-05-04-MultipleLandingPadSuccs.ll was creating duplicate successor list entries. llvm-svn: 162222
-
Jordan Rose authored
This is used to handle functions and methods that consume an argument (annotated with the ns_consumed or cf_consumed attribute), but then the argument's retain count may be further modified in a callback. We want to warn about over-releasing, but we can't really track the object afterwards. llvm-svn: 162221
-
Jordan Rose authored
Also, suggest 'readonly' even if the property has been given an ownership attribute ('strong', 'weak', etc). This is used when properties are declared readonly in the public interface but readwrite in a class extension. <rdar://problem/11500004&11932285> llvm-svn: 162220
-
Sebastian Pop authored
This patch allows us to use cmake to specify a cross compiler: target different than host. In particular, it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them available at configure time. Here is the command line that I have used to test my patches to create a Hexagon cross compiler hosted on x86: $ cmake -G Ninja -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu .. $ ninja check llvm-svn: 162219
-
Sebastian Pop authored
The patch adds a missing case for the Hexagon target in cmake/config-ix.cmake. llvm-svn: 162218
-
Sebastian Pop authored
llvm-svn: 162217
-
Jordan Rose authored
No functionality change. llvm-svn: 162216
-
Jordan Rose authored
Generating a sink is significantly different behavior from generating a normal node, and a simple boolean parameter can be rather opaque. Per offline discussion with Anna, adding new generation methods is the clearest way to communicate intent. No functionality change. llvm-svn: 162215
-