As brought up on cfe-commits[1], r334650 causes the dependency of the
out parameter to the __builtin_*_overflow functions to be ignored. The result
was a usage that was otherwise constexpr (both operands to the operation were
constexpr) would be evaluated, but the out parameter wouldn't be modified, so
it would still be 'undef'.
This patch correctly handles the return value of handleAssignment to ensure that
this value is properly considered/evaluated.
[1] http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180702/233667.html
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336364 91177308-0d34-0410-b5e6-96231b3b80d8
by providing a memchr builtin that returns char* instead of void*.
Also add a __has_feature flag to indicate the presence of constexpr forms of
the relevant <string> functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292555 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't seek "entry:" It dosen't appear with -Asserts.
- Take care that Codegen'ed Instruction(s) wouldn't have name(s) in -Asserts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193908 91177308-0d34-0410-b5e6-96231b3b80d8
long in linux 64 is 64 bits but is always 32 bits on windows. The lit test was modified
to use long long instead of long and check for 64-bit mangling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193901 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193896 91177308-0d34-0410-b5e6-96231b3b80d8
& operator (ignoring any overloaded operator& for the type). The purpose of
this builtin is for use in std::addressof, to allow it to be made constexpr;
the existing implementation technique (reinterpret_cast to some reference type,
take address, reinterpert_cast back) does not permit this because
reinterpret_cast between reference types is not permitted in a constant
expression in C++11 onwards.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186053 91177308-0d34-0410-b5e6-96231b3b80d8
This test was written to make sure *something* sane is generated, not
to test any ABI's signedness semantics.
This should allow the test to pass if AArch64 is the default target.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174618 91177308-0d34-0410-b5e6-96231b3b80d8
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162962 91177308-0d34-0410-b5e6-96231b3b80d8
to look through SubstNonTypeTemplateParmExprs. Then, update the IR
generation of CallExprs to actually use CallExpr::getCalleeDecl()
rather than attempting to mimick its behavior (badly).
Fixes <rdar://problem/10063539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139185 91177308-0d34-0410-b5e6-96231b3b80d8
inconsistent with the type that the builtin *should* have, forget
about the builtin altogether: we don't want subsequence analyses,
CodeGen, etc., to think that we have a proper builtin function.
C is protected from errors here because it allows one to use a
library builtin without having a declaration, and detects inconsistent
(re-)declarations of builtins during declaration merging. C++ was
unprotected, and therefore would crash.
Fixes PR8839.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122351 91177308-0d34-0410-b5e6-96231b3b80d8
Erich Keane