The assertion was failing when a method of a parameterized class was
called and the types of the argument and parameter didn't match. To fix
the failure, move the assertion in EmitCallArg to its only caller
EmitCallArgs and require the argument and parameter types match only
when the method is not parameterized.
rdar://problem/32874473
Differential Revision: https://reviews.llvm.org/D34665
llvm-svn: 306494
According to the documentation, when encoding a bit-field, GNU runtime
needs its starting position in addition to its type and size.
https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html
Prior to r297702, the starting position information was not being
encoded, which is incorrect, and after r297702, an assertion started to
fail because an ObjCIvarDecl was being passed to a function expecting a
FieldDecl.
This commit moves LookupFieldBitOffset to ASTContext and uses the
function to encode the starting position of bit-fields.
llvm-svn: 306364
This patch makes ubsan's nonnull return value diagnostics more precise,
which makes the diagnostics more useful when there are multiple return
statements in a function. Example:
1 |__attribute__((returns_nonnull)) char *foo() {
2 | if (...) {
3 | return expr_which_might_evaluate_to_null();
4 | } else {
5 | return another_expr_which_might_evaluate_to_null();
6 | }
7 |} // <- The current diagnostic always points here!
runtime error: Null returned from Line 7, Column 2!
With this patch, the diagnostic would point to either Line 3, Column 5
or Line 5, Column 5.
This is done by emitting source location metadata for each return
statement in a sanitized function. The runtime is passed a pointer to
the appropriate metadata so that it can prepare and deduplicate reports.
Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298
Differential Revision: https://reviews.llvm.org/D34299
llvm-svn: 306163
Fix the type for a (runtime) library call to match both the comment and
the runtime implementation. As it happens, the type being used matched,
this just makes it more precise.
llvm-svn: 305638
This changes the codegen to match the section names according to the
ObjC rewriter as well as the runtime. The changes to the test are
simply whitespace changes to the section attributes and names and are
functionally equivalent (the whitespace is ignored by the linker).
llvm-svn: 304661
The assertion fails because EmitValueForIvarAtOffset doesn't get the
correct type of the ivar when the class the ivar belongs to is
parameterized. This commit fixes the function to compute the ivar's type
based on the type argument provided to the parameterized class.
rdar://problem/32461723
Differential Revision: https://reviews.llvm.org/D33698
llvm-svn: 304449
Amongst other, this will help LTO to correctly handle/honor files
compiled with O0, helping debugging failures.
It also seems in line with how we handle other options, like how
-fnoinline adds the appropriate attribute as well.
Differential Revision: https://reviews.llvm.org/D28404
llvm-svn: 304127
blocks.
r302270 made changes to avoid emitting clang.arc.use at -O0 and instead
emit @objc_release. We also have to emit @objc_retain for the captured
variable at -O0 to match the @objc_release instead of just storing the
pointer to the capture field.
llvm-svn: 302495
The clang.arc.use intrinsic is removed via the ARC Contract Pass. This
pass is only executed in optimized builds (>= opt level 1). Prevent the
optimization implemented in SVN r301667 from triggering at optimization
level 0 like every other ARC use intrinsic usage.
llvm-svn: 302270
creation that are const-qualified.
When a block captures an ObjC object pointer, clang retains the pointer
to prevent prematurely destroying the object the pointer points to
before the block is called or copied.
When the captured object pointer is const-qualified, we can avoid
emitting the retain/release pair since the pointer variable cannot be
modified in the scope in which the block literal is introduced.
For example:
void test(const id x) {
callee(^{ (void)x; });
}
This patch implements that optimization.
rdar://problem/28894510
Differential Revision: https://reviews.llvm.org/D32601
llvm-svn: 301667
Fix the nullability-assign check so that it can handle assignments into
C++ structs. Previously, such assignments were not instrumented.
Testing: check-clang, check-ubsan, enabling the existing test in ObjC++
mode, and building some Apple frameworks with -fsanitize=nullability.
llvm-svn: 301482
available.
Original patch by Douglas Gregor with minor modifications.
This recommits r300389, which broke bots because there have been API
changes since the original patch was written.
rdar://problem/20689633
llvm-svn: 300396
CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). This patch keeps the loop variable alive for the whole loop by extending ForScope and registering the cleanup function inside EmitAutoVarAlloca.
Differential Revision: https://reviews.llvm.org/D32029
llvm-svn: 300340
CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). The markers of the loop variable need to be either both inside the loop (so that we poison and unpoison the variable in each iteration), or both outside. This patch implements the "both inside" approach.
Differential Revision: https://reviews.llvm.org/D32029
llvm-svn: 300287
After r297760, __isOSVersionAtLeast in compiler-rt loads the CoreFoundation
symbols at runtime. This means that `@available` will always fail when used in a
binary without a linked CoreFoundation.
This commit forces Clang to emit a reference to a CoreFoundation symbol when
`@available` is used to ensure that linking will fail when CoreFoundation isn't
linked with the build product.
rdar://31039592
Differential Revision: https://reviews.llvm.org/D30977
llvm-svn: 298588
This is a follow-up to r297700 (Add a nullability sanitizer).
It addresses some FIXME's re: using nullability-specific diagnostic
handlers from compiler-rt, now that the necessary handlers exist.
check-ubsan test updates to follow.
llvm-svn: 297750
Teach UBSan to detect when a value with the _Nonnull type annotation
assumes a null value. Call expressions, initializers, assignments, and
return statements are all checked.
Because _Nonnull does not affect IRGen, the new checks are disabled by
default. The new driver flags are:
-fsanitize=nullability-arg (_Nonnull violation in call)
-fsanitize=nullability-assign (_Nonnull violation in assignment)
-fsanitize=nullability-return (_Nonnull violation in return stmt)
-fsanitize=nullability (all of the above)
This patch builds on top of UBSan's existing support for detecting
violations of the nonnull attributes ('nonnull' and 'returns_nonnull'),
and relies on the compiler-rt support for those checks. Eventually we
will need to update the diagnostic messages in compiler-rt (there are
FIXME's for this, which will be addressed in a follow-up).
One point of note is that the nullability-return check is only allowed
to kick in if all arguments to the function satisfy their nullability
preconditions. This makes it necessary to emit some null checks in the
function body itself.
Testing: check-clang and check-ubsan. I also built some Apple ObjC
frameworks with an asserts-enabled compiler, and verified that we get
valid reports.
Differential Revision: https://reviews.llvm.org/D30762
llvm-svn: 297700
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Changes since the original commit:
- Single-bit bools are a special case (see CGF::EmitFromMemory), and we
can't avoid dealing with them when loading from a bitfield. Don't try to
insert a check in this case.
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297389
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297298
UBSan's nonnull argument check applies when a parameter has the
"nonnull" attribute. The check currently works for FunctionDecls, but
not for ObjCMethodDecls. This patch extends the check to work for ObjC.
Differential Revision: https://reviews.llvm.org/D30599
llvm-svn: 296996
routines for objects that are captured with the __unsafe_unretained
ownership qualifier
This is a preparation commit that improves code-coverage in code that emits
block copy/dispose routines.
llvm-svn: 296048
Summary: AddDiscriminator pass is only useful for sample pgo. This patch restricts AddDiscriminator to -fdebug-info-for-profiling so that it does not introduce unecessary debug size increases for non-sample-pgo builds.
Reviewers: dblaikie, aprantl
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30220
llvm-svn: 295764
Certain ARC runtime functions have an ABI contract of being forwarding.
Annotate the functions with the appropriate `returned` attribute on the
arguments. This hoists some of the runtime ABI contract information
into the frontend rather than the backend transformations.
The test adjustments are to mark the returned function parameter as
such. The minor change to the IR output is due to the fact that the
returned reference of the object causes it to extend the lifetime of the
object by returning an autoreleased return value. The result is that
the explicit objc_autorelease call is no longer formed, as autorelease
elision is now possible on the return.
llvm-svn: 294872
This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.
rdar://problem/30111207
llvm-svn: 293596
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
llvm-svn: 290398
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
On some Apple platforms, the ObjC BOOL type is defined as a signed char.
When performing instrumentation for -fsanitize=bool, we'd like to treat
the range of BOOL like it's always {0, 1}. While we can't change clang's
IRGen for char-backed BOOL's due to ABI compatibility concerns, we can
teach ubsan to catch potential abuses of this type.
rdar://problem/29502773
Differential Revision: https://reviews.llvm.org/D27607
llvm-svn: 289290
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Recommit r287039 (that was reverted in r287039) with a tweak to
be more generic, and test fixes!
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287085
This allows for the coalescing of the protocol declarations. When the protocols
are declared in headers, multiple definitions of the protocol would be emitted.
Marking them as common data indicates that any one can be selected.
llvm-svn: 285073
This reverts commit r285007 and reapply r284990, with a fix for the
opencl test that I broke. Original commit message follows:
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 285019
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 284990
Preparation to implement DW_AT_alignment support:
- We pass non-zero align value to DIBuilder only when alignment was forced
- Modify tests to match this change
Differential Revision: https://reviews.llvm.org/D24426
llvm-svn: 284679
Incorrect specification of the calling convention results in UB which can cause
the code path to be eliminated. Simplify the existing code by using the
RuntimeCall constructor in `CodeGenFunction`.
llvm-svn: 284154
Summary: https://reviews.llvm.org/D25132 added discriminator even add -g0. This leads to test fail which is addressed in thie patch.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25133
llvm-svn: 283564
This eliminates a class of false positives for -fsanitize=array-bounds
on instrumented ObjC projects.
Differential Revision: https://reviews.llvm.org/D22227
llvm-svn: 283249
When ARC is enabled, an ObjCIndirectCopyRestoreExpr models the passing
of a function argument s.t:
* The argument is copied into a temporary,
* The temporary is passed into the function, and
* After the function call completes, the temporary is move-assigned
back to the original location of the argument.
The argument type and the parameter type must agree "except possibly in
qualification". This commit weakens an assertion in EmitCallArg() to
actually reflect that.
llvm-svn: 283116
These are all emitted into a section with a cstring_literal attribute. The
attribute permits the linker to coalesce the string contents. The address of
the strings are not important.
llvm-svn: 281855
These strings are constants, mark them as such. This doesn't matter too much in
practice on MachO since the constants are placed into a special section and not
referred to directly.
llvm-svn: 281854
The previous change was insufficient to mark the content as read-write as the
structure itself was marked constant. Adjust this and add tests to ensure that
the section is marked appropriately as being read-write.
llvm-svn: 277200
The test was relying on the default triple which may not be correct. Explicitly
provide it a triple. Should repair the windows on Linux builder.
llvm-svn: 275738
Add support for ObjC types to respect the DLLImport/DLLExport storage
annotations. This only effects COFF output. This would allow usage with
clang/C2, but not with clang/LLVM due to hard coded section names.
llvm-svn: 275737
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
objective-c properties.
This fixes an assert in CodeGen that fires when the getter and setter
functions for an objective-c property of type _Atomic(_Bool) are
synthesized.
rdar://problem/26322972
Differential Revision: http://reviews.llvm.org/D20407
llvm-svn: 270808
exiting the for-in loop.
This commit fixes a bug where EmitObjCForCollectionStmt didn't pop
cleanups for captures.
For example, in the following for-in loop, a block which captures self
is passed to foo1:
for (id x in [self foo1:^{ use(self); }]) {
use(x);
break;
}
Previously, the code in EmitObjCForCollectionStmt wouldn't pop the
cleanup for the captured self before exiting the loop, which caused
code-gen to generate an IR in which objc_release was called twice on
the captured self.
This commit fixes the bug by entering a RunCleanupsScope before the
loop condition is evaluated and forcing its cleanup before exiting the
loop.
rdar://problem/16865751
Differential Revision: http://reviews.llvm.org/D18618
llvm-svn: 266147
The objc_runtime_visible attribute deals with an odd corner case where
a particular Objective-C class is known to the Objective-C runtime
(and, therefore, accessible by name) but its symbol has been hidden
for some reason. For such classes, teach CodeGen to use
objc_lookUpClass to retrieve the Class object, rather than referencing
the class symbol directly.
Classes annotated with objc_runtime_visible have two major limitations
that fall out from places where Objective-C metadata needs to refer to
the class (or metaclass) symbol directly:
* One cannot implement a subclass of an objc_runtime_visible class.
* One cannot implement a category on an objc_runtime_visible class.
Implements rdar://problem/25494092.
llvm-svn: 265201
This reverts commit r263607.
This change caused more objc_retain/objc_release calls in the IR but those
are then incorrectly optimized by the ARC optimizer. Work is going to have
to be done to ensure the ARC optimizer doesn't optimize user written RR, but
that should land before this change.
This change will also need to be updated to take account for any changes required
to ensure that user written calls to RR are distinct from those inserted by ARC.
llvm-svn: 263984
It is faster to directly call the ObjC runtime for methods such as retain/release instead of sending a message to those functions.
This patch adds support for converting messages to retain/release/alloc/autorelease to their equivalent runtime calls.
Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions.
Reviewed by John McCall.
Differential Revision: http://reviews.llvm.org/D14737
llvm-svn: 263607
This is mainly for extensibility. Note that fragile category metadata,
metadata for classes and protocols all have a size field.
Initial patch was provided by Greg Parker.
rdar://problem/24804226
llvm-svn: 261756
The current macho linker just copies symbols in section datacoal_nt to
section data, so it doesn't really matter whether or not section
"datacoal_nt" is attached to the global variable.
This is a follow-up to r250370, which made changes in llvm to stop
putting functions and data in the *coal* sections.
rdar://problem/24528611
llvm-svn: 260496
Per review feedback the name was wrong and it can be used outside
Objective-C.
Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type. I'm worried that this will also affect
users' code. So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup. This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.
rdar://problem/24425801
llvm-svn: 259734
Original message:
Make CF constant string decl visible to name lookup to fix module errors
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259721
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259624
The list of class properties is saved in
Old ABI: protocol->ext->class_properties (protocol->ext->size will be updated)
New ABI: protocol->class_properties (protocol->size will be updated)
rdar://23891898
llvm-svn: 259268
The list of class properties is saved in
Old ABI: category->class_properties (category->size will be updated as well)
New ABI: category->class_properties (a flag in objc_image_info to indicate
whether or not the list of class properties is present)
rdar://23891898
llvm-svn: 259267
reclaiming a call result in order to ignore it or assign it
to an __unsafe_unretained variable. This avoids adding
an unwanted retain/release pair when the return value is
not actually returned autoreleased (e.g. when it is returned
from a nonatomic getter or a typical collection accessor).
This runtime function is only available on the latest Apple
OS releases; the backwards-compatibility story is that you
don't get the optimization unless your deployment target is
recent enough. Sorry.
rdar://20530049
llvm-svn: 258962
r251874 stopped back-patching the AST when an Objective-C 'readonly'
property is redeclared in a class extension as 'readwrite'. However,
it did not properly handle merging of Objective-C property attributes
(e.g., getter name, ownership, atomicity) to the redeclaration,
leading to bad metadata. Merge (and check!) those property attributes
so we get the right metadata and reasonable ASTs. Fixes
rdar://problem/23823989.
llvm-svn: 255309
After r251874, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make debug info emission explicitly
look for properties in class extensions before looking at direct properties.
Also add a test that checks for this. There are three interesting cases:
1. A property is only declared in a class extension, and the @implementation
is in a different file. This used to generated a DIObjcProperty before
r251874 and does again with this fix.
2. A property is declared as readonly in the class itself and redeclared as
readwrite in a class extension. clang before r251874 put the DIObjcProperty
on the first declaration. clang after r251874 didn't emit any DIObjcProperty,
and clang with this fix puts it on the readwrite redeclaration (which is
what lookup finds). This seems like a progression.
3. Like 2, but with an @implementation in the same file. In this case,
the property debug info gets generated a second time through the ivar
from the definition. In this case, lookup and declaration code need
to agree on the line number so that the DIObjcProperty isn't emitted
twice. In this case, clang before r251874 emitted one DIObjcProperty
on the first declaration, clang with r251874 emitted one on the second
declaration, and clang with this patch still does the latter.
llvm-svn: 254750
After, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make ObjCCommonMac::EmitPropertyList()
explicitly look for properties in class extensions before looking at
direct properties.
Also add a test that passes both with clang before r251874 and after this
patch (but fails with r251874 and without this patch).
llvm-svn: 254622
Summary: The frontend debuginfo tests should not invoke llvm passes which includes add-discriminators that will change the debug info generated by FE.
Reviewers: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14848
llvm-svn: 253686
Summary: The discriminator change in http://reviews.llvm.org/D14738 will fail these clang tests. Update the test to accomendate the discriminator change.
Reviewers: dblaikie, davidxl, dnovillo
Differential Revision: http://reviews.llvm.org/D14836
llvm-svn: 253595
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
llvm-svn: 253534
to start at the offset of the first ivar instead of the rounded-up
end of the superclass. The latter could include a large amount of
tail padding because of a highly-aligned ivar, and subclass ivars
can be laid out within that.
llvm-svn: 253533
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
llvm-svn: 253512
Some expected attributes appear to be incorrect after
optimizations are run and llvm will strip them. Use -O0
so that llvm will not have a chance to remove them.
llvm-svn: 253458
The C++ spec (3.6.1.3) says "The function `main` shall not be used within a program". This implies that it cannot recurse, so add the norecurse attribute to help the midend out a bit.
llvm-svn: 252902
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
This is almost entirely a matter of just flipping a switch. 99% of
the runtime support is available all the way back to when it was
implemented in the non-fragile runtime, i.e. in Lion. However,
fragile runtimes do not recognize ARC-style ivar layout strings,
which means that accessing __strong or __weak ivars reflectively
(e.g. via object_setIvar) will end up accessing the ivar as if it
were __unsafe_unretained. Therefore, when using reflective
technologies like KVC, be sure that your paths always refer to a
property.
rdar://23209307
llvm-svn: 250955
Specifically, handle under-aligned object references (by explicitly
ignoring them, because this just isn't representable in the format;
yes, this means that GC silently ignores such references), descend
into anonymous structs and unions, stop classifying fields of
pointer-to-strong/weak type as strong/weak in ARC mode, and emit
skips to cover the entirety of block layouts in GC mode. As a
cleanup, extract this code into a helper class, avoid a number of
unnecessary copies and layout queries, generate skips implicitly
instead of explicitly tracking them, and clarify the bitmap-creation
logic.
llvm-svn: 250919
CGBlocks.cpp.
This commit fixes a bug in clang's code-gen where it creates the
following functions but doesn't attach function attributes to them:
__copy_helper_block_
__destroy_helper_block_
__Block_byref_object_copy_
__Block_byref_object_dispose_
rdar://problem/20828324
Differential Revision: http://reviews.llvm.org/D13525
llvm-svn: 249735
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.
They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.
llvm-svn: 249205
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
Update testcases after LLVM change r243774.
Most of these had no need to check `tag:` field, but did so as a way of
getting to the `name:` field. In a few cases I've converted the `tag:`
checks to `arg:` or `CHECK-NOT: arg:`.
llvm-svn: 243775
Currently, -save-temp will cause ObjCARC optimization to be dropped,
sanitizer pass to run early in the pipeline, and profiling
instrumentation to run twice.
Fix the issue by properly disable all passes in the optimization
pipeline when generating bitcode output and parse some of the Language
Options even when the input is bitcode so the passes can be setup
correctly.
llvm-svn: 242565
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
Example:
@interface NSSet<T : id<NSCopying>> : NSObject <NSCopying>
- (T)firstObject;
@end
void f(NSSet<NSString *> *stringSet, NSSet *anySet) {
[stringSet firstObject]; // produces NSString*
[anySet firstObject]; // produces id<NSCopying> (the bound)
}
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
llvm-svn: 241543
Several tests wouldn't pass when executed on an armv7a_pc_linux triple
due to the non-default arm_aapcs calling convention produced on the
function definitions in the IR output. Account for this with the
application of a little regex.
Patch by Ying Yi.
llvm-svn: 240971
While the rest of the Objective-C metadata seems to honor
objc_runtime_name, the encoding strings produced by, e.g., @encode and
property meta, were not. Fixes rdar://problem/21408305.
llvm-svn: 239852
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.
llvm-svn: 235553
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.
llvm-svn: 234581
Now if you break on a dtor and go 'up' in your debugger (or you get an
asan failure in a dtor) during an exception unwind, you'll have more
context. Instead of all dtors appearing to be called from the '}' of the
function, they'll be attributed to the end of the scope of the variable,
the same as the non-exceptional dtor call.
This doesn't /quite/ remove all uses of CurEHLocation (which might be
nice to remove, for a few reasons) - it's still used to choose the
location for some other work in the landing pad. It'd be nice to
attribute that code to the same location as the exception calls within
the block and to remove CurEHLocation.
llvm-svn: 228181
is for each machine. Fix up darwin tests that were testing for
aapcs on armv7-ios when the actual ABI is apcs.
Should be no user visible change without -cc1.
llvm-svn: 223429
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
llvm-svn: 222993
When emitting nested block definitions, the insert-at-point variant of
DIBuilder::insertDeclare() could be called with the insertion point set
to the end-of-BasicBlock sentinel, causing the parent pointer of the
CallInst to be set to the intentionally bogus value of the sentinel.
Fixed by conditionally invoking the correct version of insertDeclare().
rdar://problem/19034882
llvm-svn: 222487
Mangling for blocks defined within blocks in an ObjectiveC context were also
broken by SVN r219393. Because the code in mangleName assumed that the code was
either C or C++, we would trigger assertions when trying to mangle the inner
blocks in an ObjectiveC context.
Add a test and use the ObjectiveC specific mangling when dealing with an
ObjectiveC method declaration.
llvm-svn: 219697
Boostrapping LLVM+Clang+LLDB without threshold on object size for
lifetime markers insertion has shown there was no significant change
in compile time, so let the stack slot colorizer do its optimization
for all slots.
llvm-svn: 219303
This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.
--
Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.
Part of PR17891.
llvm-svn: 219011
Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.
Part of PR17891.
llvm-svn: 218913
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.
http://reviews.llvm.org/D4919
rdar://problem/17994491
llvm-svn: 218788
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.
http://reviews.llvm.org/D4919
rdar://problem/17994491
llvm-svn: 218777
linkage related to generation of OBJC_SELECTOR_REFERENCES symbol
needed in generation of call to 'super' in a class method.
// rdar://18150301
llvm-svn: 216676
This broke the following gdb tests:
gdb.base__annota1.exp
gdb.base__consecutive.exp
gdb.python__py-symtab.exp
gdb.reverse__consecutive-precsave.exp
gdb.reverse__consecutive-reverse.exp
I will look into this.
This reverts commit 214162.
llvm-svn: 214163
This allows us to give more precise diagnostics.
Diego kindly tested the impact on debug info size: "The increase on average
debug sizes is 0.1%. The total file size increase is ~0%."
llvm-svn: 214162
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.
Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.
llvm-svn: 213386
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
llvm-svn: 213167
This looks like the right way for this check to work, but there is
another semi-obvious bug, I would think: why is CurLoc not zero'd out
between functions? The possibility for it to bleed between them seems
problematic. (& indeed I caused tests to fail when I fixed this a
different way, by setting CurLoc to SourceLocation() and the end of
EmitFunctionEnd... )
The changes to debug-info-blocks.m are due to a mismatch between the
source manager's file naming and CGDebugInfo's default handling when no
-main-file-name is specified. This actually reveals somewhat of a bug in
the debug info when using source files from standard in, too. See the
comment in CGDebugInfo::CreateCompileUnit for more details.
llvm-svn: 208742
This takes a different approach than the
completedType/requiresCompleteType work which relies on AST callbacks to
upgrade the type declaration to a definition. Instead, just defer
constructing the definition to the end of the translation unit.
This works because the definition is never needed by other debug info
(so far as I know), whereas the definition of a struct may be needed by
other debug info before the end of the translation unit (such as
emitting the definition of a member function which must refer to that
member function's declaration).
If we had a callback for whenever an IVar was added to an ObjC interface
we could use that, and remove the need for the ObjCInterfaceCache, which
might be nice. (also would need a callback for when it was more than
just a declaration so we could get properties, etc).
A side benefit is that we also don't need the CompletedTypeCache
anymore. Just rely on the declaration-ness of a type to decide whether
its definition is yet to be emitted.
There's still the PR19562 memory leak, but this should hopefully make
that a bit easier to approach.
llvm-svn: 208015
and no return expr at the end of the function.
The "function has only simple returns" check in FinishFunction tests
whether the number of simple return exprs equals the number of return
exprs, but so far a fallthrough at the end of a function was not counted
as a return, which would result in cleanup code being associated with the
wrong source line.
rdar://problem/16733984.
llvm-svn: 207480
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
These tests are logically related, but they're spread about several
different CodeGen directories. Consolidate them in one place to make
them easier to manage.
llvm-svn: 203541
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.
The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.
llvm-svn: 203172
This expected;
; Function Attrs: uwtable
define internal void @"\01+[A foreach:]"(i8* %self, i8* %_cmd, %0* %array) #0 {
But the Name is mangled on other hosts; (x86_64-unknown-unknown)
; Function Attrs: nounwind uwtable
define internal void @_c_A__foreach_(i8* %self, i8* %_cmd, %1* %array) #0 {
llvm-svn: 203092
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
if an ivar offset load is invariant iff inside an instance method
and ivar belongs to instance method's class and one of its super class.
// rdar://16095748
llvm-svn: 202872
Akira Hatanaka