For global reg lvalue - use regular store through global register.
For simple lvalue - use simple atomic store.
For bitfields, vector element, extended vector elements - the original value of the whole storage (for vector elements) or of some aligned value (for bitfields) is atomically read, the part of this value for the given lvalue is modified and then use atomic compare-and-exchange operation to try to atomically write modified value (if it was not modified).
Also, changes in this patch fix the bug for '#pragma omp atomic read' applied to extended vector elements.
Differential Revision: http://reviews.llvm.org/D7369
llvm-svn: 230736
The __finally emission block tries to be clever by removing unused continuation
edges if there's an unconditional jump out of the __finally block. With
exception edges, the EH continuation edge isn't always unused though and we'd
crash in a few places.
Just don't be clever. That makes the IR for __finally blocks a bit longer in
some cases (hence small and behavior-preserving changes to existing tests), but
it makes no difference in general and it fixes the last crash from PR22553.
http://reviews.llvm.org/D7918
llvm-svn: 230697
MSVC doesn't warn on this. Users are expected to apply the WINAPI macro
to functions passed by pointer to the Win32 API, and this macro expands
to __stdcall. This means we end up with a lot of useless noisy warnings
about ignored calling conventions when compiling code with clang for
Win64.
llvm-svn: 230668
Currently, the NaN values emitted for MIPS architectures do not cover
non-IEEE754-2008 compliant case. This change fixes the issue.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D7882
llvm-svn: 230653
Change -fsanitize-memory-track-origins to be equivalent to
-fsanitize-memory-track-origins=2.
Track-origins=2 provides a lot more detailed reports at the cost of
some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on
SPEC2006).
llvm-svn: 230644
Before:
Aaaa aaaaaaaaaaa{
{
a, // +1 indent weird.
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
After:
Aaaa aaaaaaaaaaa{
{
a, // better!?
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
Interesting that this apparently was entirely untested :-(.
llvm-svn: 230627
There is no supported toolchain which provides headers / libs / object
files specific to the mips32r[3|5] and mips64r[3|5] ISA. So select "r2"
specific folders when they are available.
http://reviews.llvm.org/D7879
llvm-svn: 230611
Use the newly minted `DIImportedEntity` default constructor (r230609)
rather than explicitly specifying `nullptr`. The latter will become
ambiguous when the new debug info hierarchy is committed, since we'll
have both of the following:
explicit DIImportedEntity(const MDNode *);
DIImportedEntity(const MDImportedEntity *);
(Currently we just have the former.)
A default constructor is just as clear.
llvm-svn: 230610
Fix for PR22017. Integer template arguments are automatically bit extended to
the size of the integer type. In template diffing, evaluated expressions were
not having their results extending, leading to comparing two APSInt's with
different widths. Apply the proper bit extending when evaluating template
arguments. This mainly affected bool template arguments.
llvm-svn: 230603
are now:
FrontendTool -> StaticAnalyzer/Frontend -> Frontend -> StaticAnalyzer/Core
The final dependency edge here is probably removable: AnalyzerOptions (and
Analyses.def) should probably live in Basic rather than StaticAnalyzer/Core.
llvm-svn: 230600
We'd diagnose an __assume expression which contained a function call.
This would result in us wrongly returning ExprError, causing mysterious
failures later on.
llvm-svn: 230597
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
Do not declare sized deallocation functions dependently on whether it is found in global scope. Instead, enforce the branching in emitted code by (1) declaring the functions extern_weak and (2) emitting sized delete expressions as a branching between both forms delete.
llvm-svn: 230580
one can give us more lookup results (due to implicit special members). Be sure
to complete the redecl chain for every kind of DeclContext before performing a
lookup into it, rather than only doing so for NamespaceDecls.
llvm-svn: 230558
Previously we allowed these casts only for constants declared in system
headers, which we assume are retain/release-neutral. Now also allow them
for constants in user headers, treating them as +0. Practically, this
means that we will now allow:
id x = (id)kMyGlobalConst;
But unlike with system headers we cannot mix them with +1 values:
id y = (id)(b ? kMyGlobalConst : [Obj newValAtPlusOne]); // error
id z = (id)(b ? kSystemGlobalConst: [Obj newValAtPlusOne]); // OK
Thanks to John for suggesting this improvement.
llvm-svn: 230534
While it's true that we don't create the PDB as requested on the command
line, this is a well-documented limitation. Warning about it doesn't
help people using legacy build systems with clang-cl, and it makes the
clang-cl self-host very noisy.
llvm-svn: 230527
Nico Weber