| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
layer of inderection with std::list
llvm-svn: 153847
|
| |
|
|
| |
llvm-svn: 153819
|
| |
|
|
|
|
|
|
| |
to do a nil check for the result of the call.
rdar://10950973
llvm-svn: 153793
|
| |
|
|
|
|
| |
literals. wip. // rdar://10803676
llvm-svn: 153784
|
| |
|
|
|
|
|
| |
in the fragile and non-fragile Mac ObjC runtimes. No useful test
case. Fixes rdar://problem/11072576.
llvm-svn: 153778
|
| |
|
|
|
|
|
|
| |
the function body, but do so in a way that doesn't make any assumptions
about the static local actually having a proper, unique mangling,
since apparently we don't do that correctly at all.
llvm-svn: 153776
|
| |
|
|
|
|
| |
member function is deleted.
llvm-svn: 153773
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.
Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.
llvm-svn: 153768
|
| |
|
|
|
|
| |
literals. // rdar://10803676
llvm-svn: 153756
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the nested-name-specifier (e.g., because it is dependent), do not
error even though we can't represent it in the AST at this point.
This is a horrible, horrible hack. The actual feature we still need to
implement (for C++98!) is covered by PR12292. However, we used to
silently accept this code, so when we recently started rejecting it we
caused some regressions (e.g., <rdar://problem/11147355>). This hack
brings us back to the passable-but-not-good state we had previously.
llvm-svn: 153752
|
| |
|
|
|
|
| |
other things which might mess with the variable's type.
llvm-svn: 153733
|
| |
|
|
|
|
| |
parentheses around uses of vector macro arguments.
llvm-svn: 153732
|
| |
|
|
|
|
|
|
| |
Fixes a false positive (radar://11152419). The current solution of
adding the info into 3 places is quite ugly. Pending a generic pointer
escapes callback.
llvm-svn: 153731
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
count.
This is an optimization for "retry without inlining" option. Here, if we
failed to inline a function due to reaching the basic block max count,
we are going to store this information and not try to inline it
again in the translation unit. This can be viewed as a function summary.
On sqlite, with this optimization, we are 30% faster then before and
cover 10% more basic blocks (partially because the number of times we
reach timeout is decreased by 20%).
llvm-svn: 153730
|
| |
|
|
|
|
|
| |
The way we handle this implicitly removes the ability to use
property l-values in this position, but that's really okay.
llvm-svn: 153729
|
| |
|
|
|
|
| |
pre-c++11-compatible.
llvm-svn: 153728
|
| |
|
|
|
|
| |
is causing the gdb test failures on the bots.
llvm-svn: 153727
|
| |
|
|
| |
llvm-svn: 153726
|
| |
|
|
|
|
| |
in ARC, under the usual reasoning limiting the use of __autoreleasing.
llvm-svn: 153725
|
| |
|
|
| |
llvm-svn: 153724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the case that the variable already exists. Partly this is just
protection against people making crazy declarations with custom
asm labels or extern "C" names that intentionally collide with
the manglings of such variables, but the main reason is that we
can actually emit a static local variable twice with the
requirement that it match up. There may be other cases with
(e.g.) the various nested functions, but the main exemplar is
with constructor variants, where we can be forced into
double-emitting the function body under certain circumstances
like (currently) the presence of virtual bases.
llvm-svn: 153723
|
| |
|
|
|
|
| |
inheritance.
llvm-svn: 153722
|
| |
|
|
| |
llvm-svn: 153721
|
| |
|
|
|
|
| |
in general. Found by inspection.
llvm-svn: 153720
|
| |
|
|
|
|
| |
methods with related result types. PR12384.
llvm-svn: 153716
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.
Fixes rdar://11026482
llvm-svn: 153714
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).
Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>
llvm-svn: 153710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference is going to message the setter, the getter, or both.
Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.
[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.
[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.
The general idea has the seal of approval by John.
rdar://11151621
llvm-svn: 153709
|
| |
|
|
|
|
| |
braced-initializers. <rdar://problem/11121178>.
llvm-svn: 153703
|
| |
|
|
| |
llvm-svn: 153698
|
| |
|
|
| |
llvm-svn: 153678
|
| |
|
|
| |
llvm-svn: 153674
|
| |
|
|
| |
llvm-svn: 153673
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM intrinsics for.
I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt. It's currently here:
http://people.freebsd.org/~theraven/atomic.c
It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...
llvm-svn: 153666
|
| |
|
|
| |
llvm-svn: 153665
|
| |
|
|
|
|
|
| |
visibility directives for a variety of exported
meta-data symbols. // rdar://11144048
llvm-svn: 153663
|
| |
|
|
|
|
| |
testers.
llvm-svn: 153660
|
| |
|
|
|
|
|
|
| |
in the property debug info. Any more isn't necessary after all.
rdar://11144023
llvm-svn: 153659
|
| |
|
|
| |
llvm-svn: 153658
|
| |
|
|
| |
llvm-svn: 153648
|
| |
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/docs/SourceLevelDebugging.html#objcproperty
including type and DECL. Expand the getter and setter names
into the fully qualified names.
rdar://11144023
llvm-svn: 153640
|
| |
|
|
|
|
|
| |
with libunwind installed.
Patch by Jeffrey Yasskin!
llvm-svn: 153633
|
| |
|
|
|
|
|
| |
diagnostic and a fix-it to explain to the user where the ellipsis is
supposed to go.
llvm-svn: 153622
|
| |
|
|
|
|
|
|
|
| |
in the interface, got its attribute rewritten twice, resulting in
'weakweak' or 'strongstrong'.
rdar://11047179
llvm-svn: 153621
|
| |
|
|
|
|
| |
Add a test for this too.
llvm-svn: 153616
|
| |
|
|
|
|
|
| |
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value. Fixes PR12204.
llvm-svn: 153613
|
| |
|
|
| |
llvm-svn: 153591
|
| |
|
|
|
|
| |
Patch by Dmitri Shubin!
llvm-svn: 153585
|
| |
|
|
|
|
|
| |
provide 'fixit' hint when dictionary index
is not of proper type. // rdar://11062080
llvm-svn: 153584
|
| |
|
|
|
|
|
|
| |
retry without inlining.
(+ other minor cleanups)
llvm-svn: 153581
|