offset accumulation to use a boring APInt instead of ConstantExprs.
I didn't go all the way to an 'int64_t' because I wanted APInt to handle
any magic required to properly wrap the arithmetic when the pointer
width is <64 bits. If there is a significant penalty from using APInt
here, first off WTF, and secondly let me know and I'll do the math by
hand.
I've left one layer still operating w/ ConstantExpr because it makes the
interface quite a bit simpler, and that one isn't iterative so has much
lower cost.
I suppose this may potentially speed up some strang compilation
situations, but I don't really expect much. It should have no functional
impact either way.
llvm-svn: 152590
FYI,
On VS10, %INCLUDE% contains;
(VS10)\VC\INCLUDE
(VS10)\VC\ATLMFC\INCLUDE
(SDK70A)\include
On VS11,
(VS11)\VC\INCLUDE
(VS11)\VC\ATLMFC\INCLUDE
(SDK80)\include\shared
(SDK80)\include\um
(SDK80)\include\winrt
FIXME: It may be enabled also on mingw.
llvm-svn: 152589
The LIBRARY_PATH environment variable should be honored by clang. Have the
driver pass the directories to the linker.
<rdar://problem/9743567> and PR10296.
llvm-svn: 152578
functions that includes an explicit template argument list, perform
an inner deduction against each of the function templates in that list
and, if successful, use the result of that deduction for the outer
template argument deduction. Fixes PR11713.
llvm-svn: 152575
std::string has a summary provider
std::vector std::list and std::map have both a summary and a synthetic children provider
Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two
The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic)
The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because
(a) we need different compiler flags for libc++ than for libstdcpp
(b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference
llvm-svn: 152570
serialized
-Don't add methods of invalid objc containers to the global method pool.
This protects us from trying to serialize a method whose container was not
serialized.
Part of rdar://11007039.
llvm-svn: 152566
candidate set for subsequent inlining, try to simplify the arguments to
the inner call site now that inlining has been performed.
The goal here is to propagate and fold constants through deeply nested
call chains. Without doing this, we loose the inliner bonus that should
be applied because the arguments don't match the exact pattern the cost
estimator uses.
Reviewed on IRC by Benjamin Kramer.
llvm-svn: 152556
Typically instcombine has handled this, but pointer differences show up
in several contexts where we would like to get constant folding, and
cannot afford to run instcombine. Specifically, I'm working on improving
the constant folding of arguments used in inline cost analysis with
instsimplify.
Doing this in instsimplify implies some algorithm changes. We have to
handle multiple layers of all-constant GEPs because instsimplify cannot
fold them into a single GEP the way instcombine can. Also, we're only
interested in all-constant GEPs. The result is that this doesn't really
replace the instcombine logic, it's just complimentary and focused on
constant folding.
Reviewed on IRC by Benjamin Kramer.
llvm-svn: 152555
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
To link with -static -lclang, linker tries to seek not libclang.so, clang.dll nor libclang.dll.a, but libclang.a. USEDLIBS should have correct dependencies for -static.
(In contrast, USEDLIBS=libclang.so might be enough w/o -static)
FYI, cygwin build (in buildbot) is using -static, due to avoiding weirdness of extremely slower startup lag of clang.exe.
llvm-svn: 152539
Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.
llvm-svn: 152533
Nick Kledzik