| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our BugReporter knows how to deal with implicit statements: it looks in
the ParentMap until it finds a parent with a valid location. However, since
initializers are not in the body of a constructor, their sub-expressions are
not in the ParentMap. That was easy enough to fix in AnalysisDeclContext.
...and then even once THAT was fixed, there's still an extra funny case
of Objective-C object pointer fields under ARC, which are initialized with
a top-level ImplicitValueInitExpr. To catch these cases,
PathDiagnosticLocation will now fall back to the start of the current
function if it can't find any other valid SourceLocations. This isn't great,
but it's miles better than a crash.
(All of this is only relevant when constructors and destructors are being
inlined, i.e. under -cfg-add-initializers and -cfg-add-implicit-dtors.)
llvm-svn: 160810
|
| |
|
|
|
|
|
|
| |
This workaround is fairly lame: we simulate the first element's constructor
and destructor and rely on the region invalidation to "initialize" the rest
of the elements.
llvm-svn: 160809
|
| |
|
|
|
|
|
| |
This uses CFG to tell if a constructor call is for a member, and uses
the member's region appropriately.
llvm-svn: 160808
|
| |
|
|
|
|
|
|
|
| |
Previously we were using ParentMap and crawling through the parent DeclStmt.
This should be at least slightly cheaper (and is also more flexible).
No (intended) functionality change.
llvm-svn: 160807
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.
This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).
llvm-svn: 160806
|
| |
|
|
|
|
|
| |
Test case in the next commit, which enables destructors under certain
circumstances.
llvm-svn: 160805
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
llvm-svn: 160804
|
| |
|
|
|
|
|
| |
At the very least this means initializer nodes for constructors and
automatic object destructors are present in the CFG.
llvm-svn: 160803
|
| |
|
|
|
|
|
| |
This avoids an assertion crash when we invalidate on a destructor call
instead of inlining it.
llvm-svn: 160802
|
| |
|
|
| |
llvm-svn: 160801
|
| |
|
|
|
|
| |
Fallout from CmpRuns.py API changes in r160314.
llvm-svn: 160800
|
| |
|
|
|
|
|
|
|
| |
linux. On my eglibc 2.13 based Debian system 'getc' is a macro defined in
/usr/include/stdio.h. This decision to make it a macro doesn't seem to
be guarded by any feature test macro as far as I can see.
llvm-svn: 160799
|
| |
|
|
| |
llvm-svn: 160798
|
| |
|
|
| |
llvm-svn: 160797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is still a work in progress.
Out-of-order CPUs usually execute instructions from multiple basic
blocks simultaneously, so it is necessary to look at longer traces when
estimating the performance effects of code transformations.
The MachineTraceMetrics analysis will pick a typical trace through a
given basic block and provide performance metrics for the trace. Metrics
will include:
- Instruction count through the trace.
- Issue count per functional unit.
- Critical path length, and per-instruction 'slack'.
These metrics can be used to determine the performance limiting factor
when executing the trace, and how it will be affected by a code
transformation.
Initially, this will be used by the early if-conversion pass.
llvm-svn: 160796
|
| |
|
|
|
|
|
|
|
|
|
|
| |
started from" in ThreadPlanStepOverRange so you don't
artificially reject stepping out of a function you stepped into when stepping through an inlined range.
Also fill in the target in the symbol context we make up for the inlined stepping range in ThreadPlanStepOut.
<rdar://problem/11765912>
llvm-svn: 160794
|
| |
|
|
| |
llvm-svn: 160791
|
| |
|
|
|
|
|
|
|
|
|
|
| |
typeinfo.cpp. Both new.cpp and typeinfo.cpp have code that is conditionally compiled
based on the LIBCXXRT and _LIBCPPABI_VERSION defines, but those files
do not currently include <cxxabi.h> in the non __APPLE__ case. The
attached patch updates those files so that for non __APPLE__ builds
<cxxabi.h> is included if available or if LIBCXXRT is set. I'm
modeling this on the recent updates to exception.cpp.
llvm-svn: 160790
|
| |
|
|
|
|
| |
is missing in method prototype. // rdar://11939584
llvm-svn: 160789
|
| |
|
|
|
|
| |
respect default arguments".
llvm-svn: 160788
|
| |
|
|
|
|
| |
Thanks Eli for noticing.
llvm-svn: 160787
|
| |
|
|
|
|
| |
<cstddef>. This was brought to my attention by Salvatore Benedetto in his port to a bare-metal coretex-m3. This exposed two test bugs where an explicit #include <cstdlib> was needed.
llvm-svn: 160786
|
| |
|
|
| |
llvm-svn: 160785
|
| |
|
|
| |
llvm-svn: 160784
|
| |
|
|
|
|
| |
block mangling
llvm-svn: 160783
|
| |
|
|
|
|
| |
-cxx-abi microsoft) now that PR13389 is fixed (mangling of return types)
llvm-svn: 160782
|
| |
|
|
| |
llvm-svn: 160780
|
| |
|
|
|
|
| |
is a temporary measure until my fix for PR13021 is ready.
llvm-svn: 160778
|
| |
|
|
| |
llvm-svn: 160777
|
| |
|
|
|
|
|
|
|
| |
hopefully make it more visible. Adjust the web-docs to have a link to
this file rather than the list itself. I described code owners as also
being gatekeepers for their part of the code, which I think is true but
isn't in the code owner explanation on the web page.
llvm-svn: 160776
|
| |
|
|
|
|
| |
with their non-AVX forms.
llvm-svn: 160775
|
| |
|
|
|
|
| |
Patch by Reed Kotler.
llvm-svn: 160774
|
| |
|
|
|
|
| |
platform-provided macro on some systems) to _LIBCPP_NORETURN.
llvm-svn: 160773
|
| |
|
|
| |
llvm-svn: 160772
|
| |
|
|
| |
llvm-svn: 160770
|
| |
|
|
|
|
|
|
|
| |
corrected the offsets for x86_64 conditional
branch instructions.
<rdar://problem/11502148>
llvm-svn: 160769
|
| |
|
|
|
|
|
|
|
|
| |
- Some cleanup(the TODOs) will be done after ObjC method inlining is
complete.
- Simplified CallEvent::getDefinition not to require ISDynamicDispatch
parameter.
- Also addressed Jordan's comments from r160530.
llvm-svn: 160768
|
| |
|
|
|
|
| |
null/uninitialized pointer.
llvm-svn: 160767
|
| |
|
|
|
|
| |
testcase.
llvm-svn: 160766
|
| |
|
|
|
|
| |
needed).
llvm-svn: 160764
|
| |
|
|
| |
llvm-svn: 160763
|
| |
|
|
| |
llvm-svn: 160762
|
| |
|
|
| |
llvm-svn: 160761
|
| |
|
|
|
|
|
|
| |
value by scanning the path, rather than assuming we have visited the '?:' operator
as a terminator (which sets a value indicating which expression to grab the
final ternary expression value from).
llvm-svn: 160760
|
| |
|
|
|
|
|
|
| |
"memset' lazily when is needed in translation of
struct-valued methods which require checkinf of nil receivers
outside their bodies. // rdar://11847319
llvm-svn: 160759
|
| |
|
|
|
|
|
| |
This simplifies MCRegisterInfo and shrinks the target descriptions a bit
more.
llvm-svn: 160758
|
| |
|
|
|
|
|
| |
encounter an invoke of an allocation function. This should fix the dragonegg
bootstrap. Testcase to follow, later.
llvm-svn: 160757
|
| |
|
|
|
|
|
|
|
|
|
| |
preparation for
calling functions. This is necessary on Mac OS X, since bad things can happen if you set
the registers of a thread that's sitting in a kernel trap.
<rdar://problem/11145013>
llvm-svn: 160756
|
| |
|
|
|
|
|
|
|
| |
TwoAddressInstructionPass.
The generated code for Atom has a different code sequence. This is realted
to commit r160749.
llvm-svn: 160755
|
| |
|
|
|
|
|
|
|
| |
have the time
to fix all the issues. Currently the code is essentially unmaintained and buggy, and
needs major revision (with coupled enhancements to the analyzer core).
llvm-svn: 160754
|