summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Bitcode/BitReaderTest.cpp
diff options
context:
space:
mode:
authorJordan Rose <jordan_rose@apple.com>2014-01-13 17:59:19 +0000
committerJordan Rose <jordan_rose@apple.com>2014-01-13 17:59:19 +0000
commitc9176072e6aae5a7a1a1b17506fe9c35b3399787 (patch)
treecda6b2b334ed5debc521e3688289a26405731d3d /llvm/unittests/Bitcode/BitReaderTest.cpp
parent54f6bd59f57150234f5d99d564c57a5c628e7ed6 (diff)
downloadbcm5719-llvm-c9176072e6aae5a7a1a1b17506fe9c35b3399787.tar.gz
bcm5719-llvm-c9176072e6aae5a7a1a1b17506fe9c35b3399787.zip
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression.
In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
Diffstat (limited to 'llvm/unittests/Bitcode/BitReaderTest.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud