| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
[[noreturn]] function are not required to also be [[noreturn]]. We still emit
calls to virtual __attribute__((noreturn)) functions as noreturn; unlike GCC,
we do require overriders to also be noreturn for that attribute.
llvm-svn: 176476
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 176469
|
| |
|
|
|
|
|
|
| |
from a lambda capture when the capture is not trivially-copyable.
rdar://13295759
llvm-svn: 176431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Generate atomicrmw operations in most of the cases when it's sensible to do
so.
- Don't crash in several common cases (and hopefully don't crash in more of
them).
- Add some better tests.
We now generate significantly better code for things like:
_Atomic(int) x;
...
x++;
On MIPS, this now generates a 4-instruction ll/sc loop, where previously it
generated about 30 instructions in two nested loops. On x86-64, we generate a
single lock incl, instead of a lock cmpxchgl loop (one instruction instead of
ten).
llvm-svn: 176420
|
| |
|
|
| |
llvm-svn: 176398
|
| |
|
|
| |
llvm-svn: 176328
|
| |
|
|
|
|
| |
function. Serves a patch we're kicking around out-of-tree.
llvm-svn: 176327
|
| |
|
|
|
|
| |
These can be easily queried by the back-end.
llvm-svn: 176304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
| |
|
|
| |
llvm-svn: 176254
|
| |
|
|
| |
llvm-svn: 176186
|
| |
|
|
| |
llvm-svn: 176174
|
| |
|
|
|
|
|
|
|
|
|
|
| |
bitfield. CGBitField::StorageAlignment holds the alignment in chars, but
emitMemcpy had been treating it as if it were held in bits, leading to
underaligned memcpys.
Related to PR15348.
Thanks very much to Chandler for the diagnosis.
llvm-svn: 176163
|
| |
|
|
| |
llvm-svn: 176159
|
| |
|
|
|
|
|
| |
Everything that cares about visibility also cares about linkage, so I just
moved it to Visibility.h instead of creating a new .h.
llvm-svn: 176155
|
| |
|
|
|
|
| |
This reverts commit ea95e4587fd13606fbf63b10a07a7d02026aa39c.
llvm-svn: 176151
|
| |
|
|
| |
llvm-svn: 176145
|
| |
|
|
| |
llvm-svn: 176137
|
| |
|
|
|
|
|
| |
This is causing some problems with some of the builders. It's non-trivial to
reset the target's features.
llvm-svn: 176133
|
| |
|
|
|
|
| |
adds ivars to an interface. Fixes rdar://13175234
llvm-svn: 176116
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176076
|
| |
|
|
|
|
| |
Avoids warning twice on same shift.
llvm-svn: 176056
|
| |
|
|
|
|
|
|
| |
This reverts commit 176009.
The commit is a likely cause of several buildbot failures.
llvm-svn: 176044
|
| |
|
|
|
|
|
| |
This is an ongoing process. Any command line option which a back-end cares about
should be added here.
llvm-svn: 176009
|
| |
|
|
| |
llvm-svn: 176003
|
| |
|
|
|
|
| |
array type.
llvm-svn: 175982
|
| |
|
|
|
|
|
|
|
|
|
|
| |
consumer
just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with
ASTConsumer::HandleTopLevelDecl.
ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls;
a consumer can treat an instantiated static data member however it wants of course.
llvm-svn: 175976
|
| |
|
|
|
|
| |
Post commit code review feedback from Matt Beaumont-Gay on r174248.
llvm-svn: 175969
|
| |
|
|
|
|
| |
Move the cold virtual method getNameForDiagnostic out of line.
llvm-svn: 175966
|
| |
|
|
|
|
| |
really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information.
llvm-svn: 175949
|
| |
|
|
| |
llvm-svn: 175936
|
| |
|
|
|
|
|
|
|
| |
and through to the debug info in the module. In order to make the
testcase a bit more efficient allow the filename to go through
compilation for compile and not assemble jobs and turn off the
extract for cases where we don't create an object.
llvm-svn: 175935
|
| |
|
|
|
|
|
| |
Some attributes make sense only on the function or on the call site, but not
both. Make this distinction here.
llvm-svn: 175918
|
| |
|
|
| |
llvm-svn: 175912
|
| |
|
|
|
|
|
|
| |
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
llvm-svn: 175900
|
| |
|
|
|
|
| |
PrintTemplateArgumentList.
llvm-svn: 175894
|
| |
|
|
|
|
| |
`-fno-builtin' on the command line.
llvm-svn: 175836
|
| |
|
|
| |
llvm-svn: 175815
|
| |
|
|
|
|
| |
By Adrian Pranti.
llvm-svn: 175793
|
| |
|
|
| |
llvm-svn: 175734
|
| |
|
|
|
|
|
|
|
|
| |
arguments in function prologue is done
with objc_StoreStrong to pair it with
similar objc_StoreStrong for release in function
epilogue. This is done with -O0 only.
// rdar://13145317
llvm-svn: 175698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
| |
|
|
|
|
|
|
| |
not the global visibility mode.
Noticed by inspection.
llvm-svn: 175479
|
| |
|
|
| |
llvm-svn: 175477
|
| |
|
|
| |
llvm-svn: 175471
|
| |
|
|
| |
llvm-svn: 175448
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
The back-end will use these values to reconfigure code generation for different
features.
llvm-svn: 175308
|