merge vector<intptr_t>::push_back() and vector<void*>::push_back() because
Enumerate() doesn't realize that "i64* null" and "i8** null" are equivalent.
llvm-svn: 124285
doesn't return immediately after then the insert position in UniqueSCEVs will
be out of date. No test because this is a memory corruption issue. Fixes PR9051!
llvm-svn: 124282
- Add ref-qualifiers to the type system; they are part of the
canonical type. Print & profile ref-qualifiers
- Translate the ref-qualifier from the Declarator chunk for
functions to the function type.
- Diagnose mis-uses of ref-qualifiers w.r.t. static member
functions, free functions, constructors, destructors, etc.
- Add serialization and deserialization of ref-qualifiers.
llvm-svn: 124281
after a 'return' in a CFGBlock. This accidentally
was working before, but the false assumption that
'return' always appeared at the end of the block
was uncovered by a recent change.
llvm-svn: 124280
I'm separately committing this because it incidentally changes some
block orderings and minor IR issues, like using a phi instead of
an unnecessary alloca.
llvm-svn: 124277
a few loops accordingly. Should be no functional change.
This is a step for more accurate cost/benefit analysis of devirt/inlining
bonuses.
llvm-svn: 124275
lvalues, nor can one take the address of an xvalue, by adding
appropriate static_cast's (in the first case) and a temporary (in the
second case).
llvm-svn: 124255
workaround relied on rvalue references binding to non-function
lvalues, while the original formulation (with std::forward) does the
right thing.
llvm-svn: 124241
With the current target revision of Clang libclangChecker no longer exists and
is not needed. Update the include path so we can get at ARM_DWARF_Registers.h
and friends.
llvm-svn: 124240
handling all CFGElement kinds. While writing
the test case, it turned out that return-noreturn.cpp
wasn't actually testing anything since it has the wrong -W
flag. That uncovered another regression with
the handling of destructors marked noreturn. WIP.
llvm-svn: 124238
for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer
the binding of an lvalue reference to a function lvalue over the
binding of an rvalue reference. This change resolves the ambiguity
with std::forward and lvalue references to function types in a way
that seems consistent with the original rvalue references proposal.
My proposed wording for this change is shown in
isBetterReferenceBindingKind(); we'll try to get this change adopted
in the C++0x working paper as well.
llvm-svn: 124236
Nick Lewycky