This section (introduced in DWARF-3) is used to define instruction address
ranges for functions that are not contiguous and can't be described
by low_pc/high_pc attributes (this is the usual case for inlined subroutines).
The patch is the first step to support fetching complete inlining info from DWARF.
Reviewed by Benjamin Kramer.
llvm-svn: 162657
provided char type other than char or wchar_t. It throw exception during
construction, so there is no chance to imbue own ctype.
This fixes http://llvm.org/bugs/show_bug.cgi?id=13698
llvm-svn: 162648
It does not consider user-defined conversions that convert an rvalue
into an lvalue and works incorrectly for types with such a conversion
operator.
For example,
struct foo
{
operator int&();
};
returns false_type.
Attached a patch that fixes this problem.
http://llvm.org/bugs/show_bug.cgi?id=13601
llvm-svn: 162644
This allows checkers (like the MallocChecker) to process the effects of the
bind. Previously, using a memory-allocating function (like strdup()) in an
initializer would result in a leak warning.
This does bend the expectations of checkBind a bit; since there is no
assignment expression, the statement being used is the initializer value.
In most cases this shouldn't matter because we'll use a PostInitializer
program point (rather than PostStmt) for any checker-generated nodes, though
we /will/ generate a PostStore node referencing the internal statement.
(In theory this could have funny effects if someone actually does an
assignment within an initializer; in practice, that seems like it would be
very rare.)
<rdar://problem/12171711>
llvm-svn: 162637
by this mode, and also check for signed left shift overflow. The rules for the
latter are a little subtle:
* neither C89 nor C++98 specify the behavior of a signed left shift at all
* in C99 and C11, shifting a 1 bit into the sign bit has undefined behavior
* in C++11, with core issue 1457, shifting a 1 bit *out* of the sign bit has
undefined behavior
As of this change, we use the C99 rules for all C language variants, and the
C++11 rules for all C++ language variants. Once we have individual
-fcatch-undefined-behavior= flags, this should be revisited.
llvm-svn: 162634
- Tweaked a parameter name in SBDebugger.h so my typemap will catch it;
- Added a SBDebugger.Create(bool, callback, baton) to the swig interface;
- Added SBDebugger.SetLoggingCallback to the swig interface;
- Added a callback utility function for log callbacks;
- Guard against Py_None on both callback utility functions;
- Added a FIXME to the SBDebugger API test;
- Added a __del__() stub for SBDebugger.
We need to be able to get both the log callback and baton from an
SBDebugger if we want to protect against memory leaks (or make the user
responsible for holding another reference to the callback).
Additionally, it's impossible to revert from a callback-backed log
mechanism to a file-backed log mechanism.
llvm-svn: 162633
A new Clang-based tool which converts for loops to use the range-based
syntax new to C++11. Three kinds of loops can be converted:
- Loops over statically allocated arrays
- Loops over containers, using iterators
- Loops over array-like containers, using operator[] and at()
Each transformation is assigned a confidence level by the tool. The
minimum require confidence level to actually apply the transformation
can be specified on the command line, but the default level should be
fine for most code.
Like other tools based on RefactoringTool, it is easiest to use this
tool with a compilation database.
llvm-svn: 162627
Unless the user specifies, the clang used for static analysis is the one
found relative to scan-build.
If the user specifies -with-analyzer, they can pick either to use
the clang bundled with Xcode (via xcrun) or they can specify
a path to clang.
llvm-svn: 162620
make sure we walk up the DC chain for the current context,
rather than allowing ourselves to get switched over to the
canonical DC chain. Fixes PR13642.
llvm-svn: 162616
Previously, instructions without a primary patterns wouldn't get their
properties inferred. Now, we use all single-instruction patterns for
inference, including 'def : Pat<>' instances.
This causes a lot of instruction flags to change.
- Many instructions no longer have the UnmodeledSideEffects flag because
their flags are now inferred from a pattern.
- Instructions with intrinsics will get a mayStore flag if they already
have UnmodeledSideEffects and a mayLoad flag if they already have
mayStore. This is because intrinsics properties are linear.
- Instructions with atomic_load patterns get a mayStore flag because
atomic loads can't be reordered. The correct workaround is to create
pseudo-instructions instead of using normal loads. PR13693.
llvm-svn: 162614
NAKAMURA Takumi