Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.
This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.
This is one of the possible refinements to our suppression heuristics.
<rdar://problem/12350829>
llvm-svn: 166941
Additionally, don't collect PostStore nodes -- they are often used in
path diagnostics.
Previously, we tried to track null arguments in the same way as any other
null values, but in many cases the necessary nodes had already been
collected (a memory optimization in ExplodedGraph). Now, we fall back to
using the value of the argument at the time of the call, which may not
always match the actual contents of the region, but often will.
This is a precursor to improving our suppression heuristic.
<rdar://problem/12350829>
llvm-svn: 166940
ELF subtarget.
The existing description string is moved from PPC64TargetInfo to its
DarwinTargetInfo subclass, to avoid any changes to the Darwin ABI.
PPC64TargetInfo now has two possible description strings: one for FreeBSD,
which requires 8-byte alignment, and a default string that requires
16-byte alignment.
I've added a test for PPC64 Linux to verify the 16-byte alignment. If
somebody wants to add a separate test for FreeBSD, that would be great.
Note that there is a companion patch to update the alignment information
in LLVM, which I am committing now as well.
llvm-svn: 166927
whether the initializer is value-dependent rather than whether we are in a
dependent context. This allows us to detect some errors sooner, and fixes a
crash-on-invalid if a dependent type leaks out to a non-dependent context in
error recovery.
llvm-svn: 166898
might have been used in constant expressions, rather than suppressing it for
variables which are const. The important thing here is that such variables
can have their values used without actually being marked as 'used'.
llvm-svn: 166896
doesn't include padding up to the alignment of the record, take this
as a cue that the alignment of the record should (conservatively) be
set to 1. This is similar to other the other cues we use to determine
that the record has a lower alignment, e.g., that the
externally-supplied layout places fields at lower offsets than we
would. Fixes <rdar://problem/12582052>; test case in LLDB.
llvm-svn: 166824
extern "C", its method definitions must be IRGen'ed
before meta-data for class is generated. Otherwise,
IRGen crashes (to say the least).
// rdar://12581683
llvm-svn: 166809
varargs parameter passing.
A strict reading of the ABI indicates that any argument with alignment greater
than 8 may require skipping doublewords in the parameter save area to align
the argument, and hence require skipping GPRs. In practice, this is not done
by GCC. The alignment restriction is used for internal alignment of a
structure, but a structure with 16-byte alignment, for example, is not
itself 16-byte aligned in the parameter save area. Although this is messy,
it has become the de facto standard used in building existing libraries.
My initial varargs support followed the ABI language, but not the de facto
standard. Running the GCC compatibility test suite exposed this issue, and
indeed showed that LLVM didn't pass parameters self-consistently with my
original logic. Removing the additional alignment logic allows the affected
tests to now pass.
I modified the ppc64-varargs-struct.c test case to remove the existing test
for generation of alignment code, which is no longer appropriate.
Built and tested on powerpc64-unknown-linux-gnu with no new regressions.
llvm-svn: 166805
only actually get the answer right if there was only a single
anonymous struct/union at that level. This is part of
<rdar://problem/11904570>; the test will go into LLDB itself.
llvm-svn: 166781
This code checks the ASM string to see if the output size is able to fit within
the variable specified as the output. For instance, scalar-to-vector conversions
may not really work. It's on by default, but can be turned off with a flag if
you think you know what you're doing.
This is placed under a flag ('-Wasm-operand-widths') and flag group ('-Wasm').
<rdar://problem/12284092>
llvm-svn: 166737
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.
Fixes <rdar://problem/12252783>
llvm-svn: 166728
the macros that are #define'd or #undef'd on the command line. This
checking happens much earlier than the current macro-definition
checking and is far cleaner, because it does a direct comparison
rather than a diff of the predefines buffers. Moreover, it allows us
to use the result of this check to skip over PCH files within a
directory that have non-matching -D's or -U's on the command
line. Finally, it improves the diagnostics a bit for mismatches,
fixing <rdar://problem/8612222>.
The old predefines-buffer diff'ing will go away in a subsequent commit.
llvm-svn: 166641
Many of our tests specify triples that are not built into clang.
In this commit we allow clang to fail loading the triple if we are only
using clang to emit llvm ir.
llvm-svn: 166543
After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.
The next commit relies on this behavior to actually test anything.
llvm-svn: 166528
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
llvm-svn: 166508
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Patch by Ed Schouten.
llvm-svn: 166498
check each of the files within that directory to determine if any of
them is an AST file that matches the language and target options. If
so, the first matching AST file is loaded. This fixes a longstanding
discrepency with GCC's precompiled header implementation.
llvm-svn: 166469
libraries have an incorrect definition of std::common_type (inherited from a
bug in the standard -- see LWG issue 2141), whereby they produce reference
types when they should not.
If we instantiate a typedef named std::common_type<...>::type, which is defined
in a system header as decltype(... ? ... : ...), and the decltype produces a
reference type, convert it to the non-reference type. (This doesn't affect any
LWG2141-conforming implementation of common_type, such as libc++'s, because the
default implementation of common_type<...>::type isn't supposed to produce a
reference type.)
This is horrible. I'm really sorry. :( Better ideas appreciated!
llvm-svn: 166455
implicitly-included PTH files during initialization, delaying the
mapping down to the "original source file" until after later in the
initialization process.
llvm-svn: 166452
failures they know how to tolerate, e.g., out-of-date input files or
configuration/version mismatches. Suppress the corresponding
diagnostics if the client can handle it.
No clients actually use this functionality, yet.
llvm-svn: 166449
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
llvm-svn: 166444
manager block and input-file information in the control block. The
source manager entries now point back into the control block. Input
files are now lazily deserialized (if validation is disabled). Reduces
Cocoa's PCH by the ~70k I added when I introduced the redundancy in
r166251.
llvm-svn: 166429
- This is an assumption that is currently hardwired into the backend, we need
to do this in order for the frontend and backend to agree.
llvm-svn: 166428
found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.
While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).
Original message:
PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.
llvm-svn: 166385
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
This is actually required by the C++ standard in
[basic.stc.dynamic.allocation]p3:
If an allocation function declared with a non-throwing
exception-specification fails to allocate storage, it shall return a
null pointer. Any other allocation function that fails to allocate
storage shall indicate failure only by throwing an exception of a type
that would match a handler of type std::bad_alloc.
We don't bother checking for the specific exception type, but just go off
the operator new prototype. This should help with a certain class of lazy
initalization false positives.
<rdar://problem/12115221>
llvm-svn: 166363
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
llvm-svn: 166361
macro expansion ranges, make sure to check all the FileID
entries that are contained in the spelling range of the
expansion for the macro argument.
Fixes rdar://12537982
llvm-svn: 166359
- We create two TargetLoweringInfo instances for different pass managers, and
they weren't consistent (the one for codegen didn't have the right info). I'm
not sure this mattered anywhere in practice.
llvm-svn: 166299
Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.
There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.
llvm-svn: 166285
This change was initially proposed as a solution to the problem highlighted by check-in r164677, i.e. that -verify will not cause a test-case failure where the compile command does not actually reference the file.
Patch reviewed by David Blaikie.
llvm-svn: 166281
constructors.
When I first moved regparm support to TargetInfo.cpp I tried to isolate it
in classifyArgumentTypeWithReg, but it is actually a lot easier to flip the
code around and check for regparm at the end of the decision tree.
Without this refactoring classifyArgumentTypeWithReg would have to duplicate
the logic about when to use non-byval indirect arguments.
llvm-svn: 166266
block, so the input files are validated early on, before we've
committed to loading the AST file. This (accidentally) fixed a but
wherein the main file used to generate the AST file would *not* be
validated by the existing validation logic.
At the moment, this leads to some duplication of filenames between the
source manager block and input-file blocks, as well as validation
logic. This will be handled via an upcoming patch.
llvm-svn: 166251
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
llvm-svn: 166236
source locations in places where it is necessary for diagnostics. By itself,
this causes assertions, so while I'm here, also fix property synthesis
for properties of C++ class type so we use so we properly set up a scope
and mark variable declarations.
<rdar://problem/12514189>.
llvm-svn: 166219
Within the body of the loop the underlying map may be modified via
Sema::AddOverloadCandidate
-> Sema::CompareReferenceRelationship
-> Sema::RequireCompleteType
to avoid the use of invalid iterators the sequence is copied first.
A reliable, though large, test case is available - it will be reduced and
committed shortly.
Patch by Robert Muth. Review by myself, Nico Weber, and Rafael Espindola.
llvm-svn: 166188
block, which stores information about how the AST file to generated,
from the AST block, which stores the actual serialized AST. The
information in the control block should be enough to determine whether
the AST file is up-to-date and compatible with the current translation
unit, and reading it should not cause any side effects that aren't
easy to undo. That way, we can back out from an attempt to read an
incompatible or out-of-date AST file.
Note that there is still more factoring to do. In particular,
information about the source files used to generate the AST file
(along with their time stamps, sizes, etc.) still resides in the
source manager block.
llvm-svn: 166166
Nadav's llvm change r165665 caused problems with an LTO bootstrap of clang,
so I'm reverting it for now, along with follow-on patches like this one.
llvm-svn: 166164
GCC and Clang both do not warn on:
struct a { virtual void func(); };
struct b: a { virtual void func(); void func(int); };
struct c: b { void func(int); using b::func; };
but if the "using" was using a::func GCC would still remain silent where Clang
would warn. This change makes Clang consistent with GCC's existing behavior.
llvm-svn: 166154
XML comment for declarations which pretty-prints
declaration. I had to XFAIL one test annotate-comments.cpp.
This test is currently unmaintainable as written.
Dmitri G., can you see what we can do about this test.
We should change this test such that adding a new tag does not wreck
havoc to the test.
llvm-svn: 166130
This actually looks through several kinds of expression, such as
OpaqueValueExpr and ExprWithCleanups. The idea is that binding and lookup
should be consistent, and so if the environment needs to be modified later,
the code doing the modification will not have to manually look through these
"transparent" expressions to find the real binding to change.
This is necessary for proper updating of struct rvalues as described in
the previous commit.
llvm-svn: 166121
In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrapped in a
MaterializeTemporaryExpr, which lets CodeGen know to create a temporary
region to store this value. However, MaterializeTemporaryExprs are /not/
created when a method is called on an rvalue struct, even though the 'this'
pointer needs a valid value. CodeGen works around this by creating a
temporary region anyway; now, so does the analyzer.
The analyzer also does this when accessing a field of a struct rvalue.
This is a little unfortunate, since the rest of the struct will soon be
thrown away, but it does make things consistent with the rest of the
analyzer.
This allows us to bring back the assumption that all known 'this' values
are Locs. This is a revised version of r164828-9, reverted in r164876-7.
<rdar://problem/12137950>
llvm-svn: 166120
has ivars that require destruction, but none that require anything
except zero-initialization. This is common in ARC and (when true
throughout a class hierarchy) permits the elimination of an
unnecessary message-send during allocation.
llvm-svn: 166088
combination of a load+objc_release; this is generally better
for tools that try to track why values are retained and
released. Also use objc_storeStrong when copying a block
(again, only at -O0), which requires us to do a preliminary
store of null in order to compensate for objc_storeStrong's
assign semantics.
llvm-svn: 166085
This is consistent/interoperable with GCC 4.7 (& __cxa_deleted_function isn't
present in 4.4 - not sure when it got added, but you'll need something with
that function available for this to work).
llvm-svn: 166069
Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
We expand varargs in clang and the call site is handled in the back end, it is
hard to match exactly how illegal vectors are handled in the backend. Therefore,
we legalize the illegal vector types in clang:
if (Size <= 32), legalize to i32.
if (Size == 64), legalize to v2i32.
if (Size == 128), legalize to v4i32.
if (Size > 128), use indirect.
rdar://12439123
llvm-svn: 166043
Jordan Rose