Age | Commit message (Collapse) | Author |
|
// rdar://13094352.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
field to be memcpy'd, rather instead of ASTContext::getTypeAlign(<Field Type>).
For packed structs the alignment of a field may be less than the alignment of
the field's type.
<rdar://problem/13338585>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
checkings and few other refactoring/cleanup.
// rdar://13094352.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'R' An address that can be sued in a non-macro load or store.
Including missing positive test case and fixed typo for r176453.
Thanks to Richard Smith for catching this!
Jack
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-Apple platforms.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176477 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
[[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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
an @function comment is not followed by a function decl.
// rdar://13094352
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We weren't treating a cf_audited_transfer CFRetain as returning +1 because
its name doesn't contain "Create" or "Copy". Oops! Fortunately, the
standard definitions of these functions are not marked audited.
<rdar://problem/13339601>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176463 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/11314476>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'R' An address that can be sued in a non-macro load or store.
This patch includes a positive test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://13066276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Tests are ordered by command in this file. It is nice to keep it that way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176445 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to original command in diagnostic. // rdar://13066276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176444 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176433 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and be sure to apply them whether or not the debugger gave
us a method declaration.
rdar://12565338
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176432 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
from a lambda capture when the capture is not trivially-copyable.
rdar://13295759
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176431 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with both -static-libgcc and -static on the commandline.
Fix a warning in the latter case due to a backwards short circuiting ||
operator in the driver. No real functionality changed here, just allows
the driver to properly consume -static-libgcc when -static is also
specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176429 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to a subscript operator.
rdar://13332183
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176428 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
linking. About to fix a bug here and there was no good test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176427 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176422 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we are looking at.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176414 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.
This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.
There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?
Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously we were assuming that we'd never ask for the sub-region bindings
of a bitfield, since a bitfield cannot have subregions. However,
unification of code paths has made that assumption invalid. While we could
take advantage of this by just checking for the single possible binding,
it's probably better to do the right thing, so that if/when we someday
support unions we'll do the right thing there, too.
This fixes a handful of false positives in analyzing LLVM.
<rdar://problem/13325522>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in AST for source fidelity and use it in diagnostics
to refer to the original format. // rdar://13066276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176387 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.
However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:
// From ClangSACheckersEmitter.cpp
recordGroupMap[group]->Checkers
In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)
We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.
<rdar://problem/13239854>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176371 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
whether we already have a method. Fixes a bug where we were
failing to properly contextually convert a message receiver
during template instantiation.
As a side-effect, we now actually perform correct method lookup
after adjusting a message-send to integral or non-ObjC pointer
types (legal outside of ARC).
rdar://13305374
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of block declarators. Document the rule we use.
Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.
rdar://10127067
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176336 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://13158394
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These can be easily queried by the back-end.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
use of stand-alone protocol as type and uses
id<proto>. Modify warning to say what compiler
is doing. // rdar//13158394
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176303 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176272 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
have their own code completion comments. Use those in
their properties in this case.
// rdar://12791315
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176271 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Related to rdar://13114142
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176227 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template parameter
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Functionality committed in r172585 but tested the function case without the
array case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176215 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Consider this case:
int *p = 0;
p = getPointerThatMayBeNull();
*p = 1;
If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the
re-assignment.
This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.
<rdar://problem/13299738>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176201 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This enables constructor inlining for types with non-trivial destructors.
The plan is to enable destructor inlining within the next month, but that
needs further verification.
<rdar://problem/12295329>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176200 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single translation unit should prevent later phases from executing. Otherwise,
this generates lots of noise in build systems. This a fallout from r173825.
Patch by Matthew Curtis <mcurtis@codeaurora.org>.
rdar://13298009
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176198 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(means n64 abi) to improve compatibility with GNU tools.
Patch by Jia Liu <proljc@gmail.com>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-fsanitize=memory. TSan/MSan also provide their versions of new/delete and should use the same strategy as ASan. Share the code that sets linker flags for all sanitizers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176178 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visibility. This requires that we keep track of "late" additions
of the visibility attribute.
This is hopefully the last followup change. It just removes the caching of
visibilities from types so that we can see new attributes even after a type has
been used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176164 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176153 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176152 91177308-0d34-0410-b5e6-96231b3b80d8
|