for caching couple of global symbols used
for generation of CF/NS string meta-data
so they are not released prematuely in certain
corner cases. // rdar:// 13598026.
Reviewed by John M.
llvm-svn: 179599
The SPARC v8 and SPARC v8 architectures are very similar, so use a base
class to share most information between them.
Include operating systems with known SPARC v9 ports.
Also fix two issues with the SPARC v8 data layout string: SPARC v8 is a
big endian target with a 64-bit aligned stack.
llvm-svn: 179596
When computing the value of ?: expression, we rely on the last expression in
the previous basic block to be the resulting value of the expression. This is
not the case for binary "?:" operator (GNU extension) in C++. As the last
basic block has the expression for the condition subexpression, which is an
R-value, whereas the true subexpression is the L-value.
Note the operator evaluation just happens to work in C since the true
subexpression is an R-value (like the condition subexpression). CFG is the
same in C and C++ case, but the AST nodes are different, which the LValue to
Rvalue conversion happening after the BinaryConditionalOperator evaluation.
Changed the logic to only use the last expression from the predecessor only
if it matches either true or false subexpression. Note, the logic needed
fortification anyway: L and R were passed but not even used by the function.
Also, change the conjureSymbolVal to correctly compute the type, when the
expression is an LG-value.
llvm-svn: 179574
While we don't do anything intelligent with pointers-to-members today,
it's perfectly legal to need a temporary of pointer-to-member type to, say,
pass by const reference. Tweak an assertion to allow this.
PR15742 and PR15747
llvm-svn: 179563
Now that we're invalidating global regions properly, we want to continue
taking advantage of a particular optimization: if all global regions are
invalidated together, we can represent the bindings of each region with
a "derived region value" symbol. Essentially, this lazily links each
global region with a single symbol created at invalidation time, rather
than binding each region with a new symbolic value.
We used to do this, but haven't been for a while; the previous commit
re-enabled this code path, and this handles the fallout.
<rdar://problem/13464044>
llvm-svn: 179554
This fixes a regression where a call to a function we can't reason about
would not actually invalidate global regions that had explicit bindings.
void test_that_now_works() {
globalInt = 42;
clang_analyzer_eval(globalInt == 42); // expected-warning{{TRUE}}
invalidateGlobals();
clang_analyzer_eval(globalInt == 42); // expected-warning{{UNKNOWN}}
}
This has probably been around since the initial "cluster" refactoring of
RegionStore, if not longer.
<rdar://problem/13464044>
llvm-svn: 179553
Some checkers ascribe different behavior to functions declared in system
headers, so when working with standard library functions it's probably best
to always have them in a standard location.
Test change only (no functionality change), but necessary for the next commit.
llvm-svn: 179552
This reverts commit r179436.
Due to caching, it was possible that we could miss overridden methods that
were introduced by categories later on.
Along with reverting the commit I also included a test case that would have caught this.
llvm-svn: 179547
non-constant constructors or non-trivial destructors. Plus bugfixes for
thread_local references bound to temporaries (the temporaries themselves are
lifetime-extended to become thread_local), and the corresponding case for
std::initializer_list.
llvm-svn: 179496
Invalid redeclarations of valid explicit declarations shouldn't
take the same path as redeclarations of implicit declarations,
and invalid local extern declarations shouldn't foul things up
for everybody else.
llvm-svn: 179482
two new options –msingle-float and –mdouble-float. These options can be
used simultaneously with float ABI selection options (-mfloat-abi,
-mhard-float, -msoft-float). They mark whether a floating-point
coprocessor supports double-precision operations.
llvm-svn: 179481
implementation of C99's attempt to control the C++ standard. *sigh*
The C99 standard says that certain macros in <stdint.h>, such as SIZE_MAX,
should not be defined when the header is included in C++ mode, unless
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined. The C++11 standard
says "Thanks, but no thanks" and C11 removed this rule, but various C library
implementations (such as glibc) follow C99 anyway.
g++ prior to 4.8 worked around the C99 / glibc behavior by defining
__STDC_*_MACROS in <cstdint>, which was incorrect, because <stdint.h> is
supposed to provide these macros too. g++ 4.8 works around it by defining
__STDC_*_MACROS in its builtin <stdint.h> header.
This change makes Clang act like g++ 4.8 in this regard: our <stdint.h> now
countermands any attempt by the C library to implement the undesired C99 rules,
by defining the __STDC_*_MACROS first. Unlike g++, we do this even in C++98
mode, since that was the intent of the C++ committee, matches the behavior
required in C11, and matches our built-in implementation of <stdint.h>.
llvm-svn: 179419
We had been defining Neon intrinsics as "static" with always_inline attributes.
If you use them from an extern inline function, you get a warning, e.g.:
static function 'vadd_u8' is used in an inline function with external linkage
This change simply adds the inline keyword to avoid that warning.
llvm-svn: 179406
There are few cases where we can track the region, but cannot print the note,
which makes the testing limited. (Though, I’ve tested this manually by making
all regions non-printable.) Even though the applicability is limited now, the enhancement
will be more relevant as we start tracking more regions.
llvm-svn: 179396
1) Driver/output-file-is-dir.c - Checks for object file which can't
be created for Hexagon since assembler is unavailable.
2) PCH/cxx-typeid.cpp - 'typeinfo' include file is unavailable for Hexagon.
llvm-svn: 179385
The new emacs integration is simpler, does not save the current file
before reformatting and ensures that emacs does not scroll as a result
of formatting.
Also explicitly set the style in clang-format tests to make them more
robust.
llvm-svn: 179372
Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
After:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.
This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.
<rdar://problem/13634363>
llvm-svn: 179351
In this code
int getZero() {
return 0;
}
void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}
}
we generate these arrows:
+-----------------+
| v
int problem = 1 / getZero();
^ |
+---+
where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.
* Arguably the best location for the division is the '/', but that's a
different problem.
<rdar://problem/13326040>
llvm-svn: 179350
This is a Darwin-SDK-specific hash criteria used to identify a
particular SDK without having to hash the contents of all of its
headers. If other platforms have such versioned files, we should add
those checks here.
llvm-svn: 179346
For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag. We now use the same
format: base type, access type and offset.
We also uniformize the scalar type node and the struct type node: name, a list
of pairs (offset + pointer to MDNode). For scalar type, we have a single pair.
These are to make implementaiton of aliasing rules easier.
llvm-svn: 179335
This new option is the default, but it is useful to have a flag to override
-mno-implicit-float by putting -mimplicit-float later on the command line.
llvm-svn: 179309
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
llvm-svn: 179305
The behavior can be overridden by setting LIT_USE_INTERNAL_SHELL=0 in
the environment.
This fixes issues with /dev/null for me and brings the test suite time
down to 30s. =D
llvm-svn: 179283
This required some tedious reordering to match clang's order.
Presumably these ObjC tests were generated based on llvm-gcc's output
ordering.
llvm-svn: 179282
It's a kind of implicit conversion, which we generally drop, but
more importantly it's got very specific placement requirements.
rdar://13617051
llvm-svn: 179254
For this source:
const int &ref = someStruct.bitfield;
We used to generate this AST:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).
We now generate this:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.
The commit also makes Clang accept this (legal) C++11 code:
int &&ref = std::move(someStruct).bitfield
PR15694 / <rdar://problem/13600396>
llvm-svn: 179250
The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be
a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object.
llvm-svn: 179221
constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.
This completes our support for inheriting constructors.
llvm-svn: 179154
The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases.
Previously:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "#line directive requires a simple digit sequence"
Now, we get:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "GNU line marker directive requires a simple digit sequence"
llvm-svn: 179139
Fariborz Jahanian