| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 175502
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".
Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).
rdar://13079314
llvm-svn: 175480
|
| |
|
|
|
|
|
|
| |
not the global visibility mode.
Noticed by inspection.
llvm-svn: 175479
|
| |
|
|
| |
llvm-svn: 175453
|
| |
|
|
| |
llvm-svn: 175448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module deserialization.
This commit introduces a set of related changes to ensure that the
declaration that shows up in the identifier chain after deserializing
declarations with a given identifier is, in fact, the most recent
declaration. The primary change involves waiting until after we
deserialize and wire up redeclaration chains before updating the
identifier chains. There is a minor optimization in here to avoid
recursively deserializing names as part of looking to see whether
top-level declarations for a given name exist.
A related change that became suddenly more urgent is to property
record a merged declaration when an entity first declared in the
current translation unit is later deserialized from a module (that had
not been loaded at the time of the original declaration). Since we key
off the canonical declaration (which is parsed, not from an AST file)
for emitted redeclarations, we simply record this as a merged
declaration during AST writing and let the readers merge them.
Re-fixes <rdar://problem/13189985>, presumably for good this time.
llvm-svn: 175447
|
| |
|
|
|
|
|
|
| |
This allows Clang to detect and deal wih __atomic_* operations properly on
AArch64. Previously we produced an error when encountering them at high
optimisation levels.
llvm-svn: 175438
|
| |
|
|
|
|
| |
Paired commit with LLVM, may produce temporary build breakage.
llvm-svn: 175427
|
| |
|
|
|
|
| |
<rdar://problem/13213575>.
llvm-svn: 175425
|
| |
|
|
|
|
| |
by matching the function name first
llvm-svn: 175395
|
| |
|
|
|
|
| |
Thanks Chandler. :)
llvm-svn: 175392
|
| |
|
|
|
|
|
|
|
|
|
| |
bitfield related issues.
The original commit broke Takumi's builder. The bug was caused by bitfield sizes
being determined by their underlying type, rather than the field info. A similar
issue with bitfield alignments showed up on closer testing. Both have been fixed
in this patch.
llvm-svn: 175389
|
| |
|
|
|
| |
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 175387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An ivar ofset cannot be marked as invariant load in all cases. The ivar offset
is a lazily initialised constant, which is dependent on an objc_msgSend
invocation to perform a fixup of the offset. If the load is being performed on
a method implemented by the class then this load can safely be marked as an
inviarant because a message must have been passed to the class at some point,
forcing the ivar offset to be resolved.
An additional heuristic that can be used to identify an invariant load would be
if the ivar offset base is a parameter to an objc method. However, without the
parameters available at hand, this is currently not possible.
Reviewed-by: John McCall <rjmccall@apple.com>
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 175386
|
| |
|
|
|
|
| |
While there, explicitly declare functions to remove warnings.
llvm-svn: 175384
|
| |
|
|
|
|
|
|
|
|
|
| |
Neither of the current clients of CFGRecStmtDeclVisitor are doing
anything with typedefs, so I assume type aliases (C++11 "using")
can be safely ignored. This was causing assertion failures in
the analyzer.
<rdar://problem/13228440>
llvm-svn: 175335
|
| |
|
|
| |
llvm-svn: 175331
|
| |
|
|
|
|
|
| |
linkonce_odr. Emit construction vtables as internal in this case, since the ABI
does not guarantee that they will be availble externally.
llvm-svn: 175330
|
| |
|
|
|
|
|
|
|
|
|
| |
until recursive loading is finished.
Otherwise we may end up with a template trying to deserialize a template
parameter that is in the process of getting loaded.
rdar://13135282
llvm-svn: 175329
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for distinguishing type vs. value visibility.
The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.
I've left behind a comment which I hope explains the
philosophy behind visibility computation.
llvm-svn: 175326
|
| |
|
|
| |
llvm-svn: 175313
|
| |
|
|
|
|
|
| |
The back-end will use these values to reconfigure code generation for different
features.
llvm-svn: 175308
|
| |
|
|
|
|
|
|
|
| |
Adds a function clang_getTypeSpelling(CXType CT) that returns
a CXString containing the underlying type.
Patch by Ben Gertzfield.
llvm-svn: 175299
|
| |
|
|
|
|
|
| |
an ivar of type pointer to a typedef'ed object.
// rdar://13190095
llvm-svn: 175298
|
| |
|
|
| |
llvm-svn: 175289
|
| |
|
|
|
|
|
|
| |
while trying to do error recovery.
rdar://13207886
llvm-svn: 175282
|
| |
|
|
|
|
|
| |
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
llvm-svn: 175281
|
| |
|
|
|
|
|
| |
cast<ObjCObjectPointerType> doesn't look through sugar, getAs does.
Fixes PR15257.
llvm-svn: 175272
|
| |
|
|
|
|
| |
microsoft; also fix vdtor calls for the ARM ABI
llvm-svn: 175271
|
| |
|
|
| |
llvm-svn: 175253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds a very simple check that if a DerivedToBase CastExpr is
operating on a value with known C++ object type, and that type is not the
base type specified in the AST, then the cast is invalid and we should
return UnknownVal.
In the future, perhaps we can have a checker that specifies that this is
illegal, but we still shouldn't assert even if the user turns that checker
off.
PR14872
llvm-svn: 175239
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).
Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.
If this needs to be reverted again it will be punted to far in the future.
llvm-svn: 175234
|
| |
|
|
|
|
| |
// rdar://13192366
llvm-svn: 175217
|
| |
|
|
|
|
|
|
| |
a property, the -Wdirect-ivar-access should not warn when
accessing the property's synthesized instance variable.
// rdar://13142820
llvm-svn: 175195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C++, constants captured by lambdas (and blocks) are not actually stored
in the closure object, since they can be expanded at compile time. In this
case, they will have no binding when we go to look them up. Previously,
RegionStore thought they were uninitialized stack variables; now, it checks
to see if they are a constant we know how to evaluate, using the same logic
as r175026.
This particular code path is only for scalar variables. Constant arrays and
structs are still unfortunately unhandled; we'll need a stronger solution
for those.
This may have a small performance impact, but only for truly-undefined
local variables, captures in a non-inlined block, and non-constant globals.
Even then, in the non-constant case we're only doing a quick type check.
<rdar://problem/13105553>
llvm-svn: 175194
|
| |
|
|
|
|
|
|
| |
before checking for its attributes.
rdar://13192395
llvm-svn: 175184
|
| |
|
|
| |
llvm-svn: 175166
|
| |
|
|
|
|
|
| |
static functions in extern "C" contexts are mangled. Should fix the
bootstrap.
llvm-svn: 175132
|
| |
|
|
|
|
|
|
|
|
| |
I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.
llvm-svn: 175119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in
extern "C" {
static NonPod foo();
}
Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.
llvm-svn: 175117
|
| |
|
|
|
|
|
| |
instantiation in order to permit devirtualization later in codegen, skip over
pure functions since those can't be devirtualization targets.
llvm-svn: 175116
|
| |
|
|
|
|
|
|
| |
in the course of property synthesis deterministic (ordered
by their type size), instead of having hashtable order
(as it is currently). // rdar://13192366
llvm-svn: 175100
|
| |
|
|
| |
llvm-svn: 175084
|
| |
|
|
|
|
|
| |
base-to-derived casts have undefined behavior if the object is not actually an
instance of the derived type.
llvm-svn: 175078
|
| |
|
|
|
|
|
|
|
| |
is inside a macro argument.
Previously we would give up and not annotate anything in the range.
rdar://11891550
llvm-svn: 175062
|
| |
|
|
| |
llvm-svn: 175054
|
| |
|
|
|
|
| |
Release+Asserts builds
llvm-svn: 175053
|
| |
|
|
| |
llvm-svn: 175045
|
| |
|
|
| |
llvm-svn: 175027
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, we were handling only simple integer constants for globals and
the smattering of implicitly-valued expressions handled by Environment for
default arguments. Now, we can use any integer constant expression that
Clang can evaluate, in addition to everything we handled before.
PR15094 / <rdar://problem/12830437>
llvm-svn: 175026
|