Commit Graph

1145 Commits

Author SHA1 Message Date
Richard Smith 61422f9665 For P0784R7: add support for explicit destructor calls and
pseudo-destructor calls in constant evaluation.

llvm-svn: 373122
2019-09-27 20:24:36 +00:00
Richard Smith 4949473353 Fix use-after-free found in Clang's testsuite.
We need to discard all remaining cleanups if an earlier cleanup failed,
otherwise we may try to rerun the remaining cleanups later, potentially
after the scope containing the object is destroyed. (This can happen
when checking a potential constant expression.)

llvm-svn: 373042
2019-09-27 05:36:16 +00:00
Richard Smith 62a95568ef For P0784R7: add support for new (std::nothrow).
llvm-svn: 373037
2019-09-27 01:26:49 +00:00
Richard Smith da1b4347e4 For P0784R7: Add support for dynamic allocation with new / delete during
constant evaluation.

llvm-svn: 373036
2019-09-27 01:26:47 +00:00
Richard Smith 457226e02a For P0784R7: add support for constexpr destructors, and call them as
appropriate during constant evaluation.

Note that the evaluator is sometimes invoked on incomplete expressions.
In such cases, if an object is constructed but we never reach the point
where it would be destroyed (and it has non-trivial destruction), we
treat the expression as having an unmodeled side-effect.

llvm-svn: 372538
2019-09-23 03:48:44 +00:00
Richard Smith 6c0894b58a Remove outdated FIXME.
llvm-svn: 372438
2019-09-20 23:12:51 +00:00
Richard Smith 397a686762 Fix assertion failure when constant evaluation of a switch jumps over an
uninitialized variable in an init-statement of a 'for' or 'if'.

llvm-svn: 372437
2019-09-20 23:08:59 +00:00
Richard Smith c667cdc850 [c++20] P1331R2: Allow transient use of uninitialized objects in
constant evaluation.

llvm-svn: 372237
2019-09-18 17:37:44 +00:00
Nandor Licker 950b70dcc7 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 371834
2019-09-13 09:46:16 +00:00
Richard Smith 045b2270ce When evaluating a __builtin_constant_p conditional, always enter
constant-folding mode regardless of the original evaluation mode.

In order for this to be correct, we need to track whether we're checking
for a potential constant expression or checking for undefined behavior
separately from the evaluation mode enum, since we don't want to clobber
those states when entering constant-folding mode.

llvm-svn: 371557
2019-09-10 21:24:09 +00:00
Roman Lebedev 2c9f83cfab Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"
Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency
graphs. (clangInterp depends on clangAST which depends on clangInterp)

This reverts r370839, which is an yet another recommit of D64146.

llvm-svn: 370874
2019-09-04 10:57:06 +00:00
Nandor Licker 32f82c9cba [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370839
2019-09-04 05:49:41 +00:00
Nandor Licker c3bdad8c1e Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370636 (git commit 8327fed947)

llvm-svn: 370642
2019-09-02 11:34:47 +00:00
Nandor Licker 8327fed947 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370636
2019-09-02 10:38:08 +00:00
Nandor Licker a6bef738bf Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370584 (git commit afcb3de117)

llvm-svn: 370588
2019-08-31 15:15:39 +00:00
Nandor Licker afcb3de117 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370584
2019-08-31 15:00:38 +00:00
Nandor Licker 0300c3536a Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370531 (git commit d4c1002e0b)

llvm-svn: 370535
2019-08-30 21:32:00 +00:00
Nandor Licker d4c1002e0b [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370531
2019-08-30 21:17:03 +00:00
Nandor Licker 5c8b94a672 Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370476 (git commit a559095054)

llvm-svn: 370481
2019-08-30 15:41:45 +00:00
Nandor Licker a559095054 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370476
2019-08-30 15:02:09 +00:00
Nandor Licker 7bd0a78fae [NFC] Test commit - sorted headers.
llvm-svn: 370412
2019-08-29 21:57:47 +00:00
Richard Sandiford eb485fbc71 Add SVE opaque built-in types
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:

   https://developer.arm.com/docs/100986/0000

It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:

   (1) trying to generate LLVM IR for the types
   (2) trying to generate debug info for the types
   (3) trying to mangle the types using the Microsoft C++ ABI
   (4) trying to @encode the types in Objective C

(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change.  There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.

The intention is that the types will become sizeless types:

   http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html

The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.

Until then, the patch sets the alignments of the types to the values
specified in the link above.  It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).

The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other.  After this patch, the two pieces of work are
essentially independent.

The patch is based on one by Graham Hunter:

   https://reviews.llvm.org/D59245

Differential Revision: https://reviews.llvm.org/D62960

llvm-svn: 368413
2019-08-09 08:52:54 +00:00
Richard Smith 9e52c43090 Treat the range of representable values of floating-point types as [-inf, +inf] not as [-max, +max].
Summary:
Prior to r329065, we used [-max, max] as the range of representable
values because LLVM's `fptrunc` did not guarantee defined behavior when
truncating from a larger floating-point type to a smaller one. Now that
has been fixed, we can make clang follow normal IEEE 754 semantics in this
regard and take the larger range [-inf, +inf] as the range of representable
values.

In practice, this affects two parts of the frontend:
 * the constant evaluator no longer treats floating-point evaluations
   that result in +-inf as being undefined (because they no longer leave
   the range of representable values of the type)
 * UBSan no longer treats conversions to floating-point type that are
   outside the [-max, +max] range as being undefined

In passing, also remove the float-divide-by-zero sanitizer from
-fsanitize=undefined, on the basis that while it's undefined per C++
rules (and we disallow it in constant expressions for that reason), it
is defined by Clang / LLVM / IEEE 754.

Reviewers: rnk, BillyONeal

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63793

llvm-svn: 365272
2019-07-06 21:05:52 +00:00
Simon Pilgrim bc7f30e85c Fix -Wcast-qual const warning. NFCI.
llvm-svn: 365031
2019-07-03 12:20:28 +00:00
Simon Pilgrim 71600be3f3 Fix MSVC "not all control paths return a value" warnings. NFCI.
llvm-svn: 365012
2019-07-03 09:54:25 +00:00
Erik Pilkington eee944e7f9 [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.

The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.

rdar://44987528

Differential revision: https://reviews.llvm.org/D62825

llvm-svn: 364954
2019-07-02 18:28:13 +00:00
Richard Smith 7939ba08ab [cxx2a] P1236R1: the validity of a left shift does not depend on the
value of the LHS operand.

llvm-svn: 364265
2019-06-25 01:45:26 +00:00
Gauthier Harnisch dea9d57d95 [clang] Small improvments after Adding APValue to ConstantExpr
Summary:
this patch has multiple small improvements related to the APValue in ConstantExpr.

changes:
 - APValue in ConstantExpr are now cleaned up using ASTContext::addDestruction instead of there own system.
 - ConstantExprBits Stores the ValueKind of the result beaing stored.
 - VerifyIntegerConstantExpression now stores the evaluated value in ConstantExpr.
 - the Constant Evaluator uses the stored value of ConstantExpr when available.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63376

llvm-svn: 364011
2019-06-21 08:26:21 +00:00
Gauthier Harnisch 0bb4d46b2b [clang] perform semantic checking in constant context
Summary:
Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics.
for example:
```
constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //#1
constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //#2
```
before the patch, #2 was diagnosed incorrectly and #1 wasn't diagnosed.
after the patch #1 is diagnosed as it should and #2 isn't.

Changes:
 - add a flag to Sema to passe in constant context mode.
 - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should.
 - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator.
 - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context.
 - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated.
 - semantic checking for initialization of constexpr variables is now done in constant context.
 - adapt test that were depending on warning changes.
 - add test.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62009

llvm-svn: 363488
2019-06-15 08:32:56 +00:00
Erich Keane fc3dfd3e35 Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.
As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was
possible to get the constexpr version of __builtin_*_overflow to give
the wrong answer.

This was because when extending the operands to fit the largest type (so
that the math could be done), the decision on whether to sign/zero
extend the operands was based on the result signedness, not on the
operands signedness.

In the reported case, (unsigned char)255 - (int)100 needed
to have each extended to the int in order to do the math.  However, when
extending the first operand to 'int', we incorrectly sign extended it
instead of zero extending.  Thus, the result didnt fit back into the
unsigned char.

The fix for this was simply to choose zero/sign extension based on the
sign of the operand itself.

Differential Revision: https://reviews.llvm.org/D62665

llvm-svn: 362157
2019-05-30 21:35:32 +00:00
Richard Smith a481b01e95 [c++2a] Fix assertion failure if we would walk over more than one level
of derived-to-base conversion path when implicitly starting union
subobject lifetimes in constant evaluation.

llvm-svn: 362147
2019-05-30 20:45:12 +00:00
Eric Fiselier ffafdb9afc Fix hang during constant evaluation of union assignment.
HandleUnionActiveMemberChange forgot to walk over a nop implicit
conversion node and got stuck in the process.

As a cleanup I changed the declaration of `E` so it can't
be accidentally accessed after the loop.

llvm-svn: 361571
2019-05-23 23:34:43 +00:00
Dmitri Gribenko a10fe832fd Fixed a -Wunused-variable warning when assertions are disabled
llvm-svn: 361353
2019-05-22 06:57:23 +00:00
Richard Smith 31c69a3d63 [c++20] P1330R0: permit simple-assignments that change the active member
of a union within constant expression evaluation.

llvm-svn: 361329
2019-05-21 23:15:20 +00:00
Richard Smith e637cbe4e4 Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but soon will be.

llvm-svn: 361328
2019-05-21 23:15:18 +00:00
Mikael Holmen 3b6b2e331f Fix compilation warning about unused variable [NFC]
Without the fix at least clang 3.6 complains with

../tools/clang/lib/AST/ExprConstant.cpp:90:24: error: unused variable 'TI' [-Werror,-Wunused-variable]
    if (TypeInfoLValue TI = B.dyn_cast<TypeInfoLValue>())
                       ^
1 error generated.

llvm-svn: 361145
2019-05-20 11:38:33 +00:00
Richard Smith a933030f84 [c++20] P1327R1: Support for typeid applied to objects of polymorphic
class type in constant evaluation.

This reinstates r360977, reverted in r360987, now that its rerequisite
patch is reinstated and fixed.

llvm-svn: 361067
2019-05-17 19:19:28 +00:00
Dmitri Gribenko 04323c24a1 Added an assertion to constant evaluation enty points that prohibits dependent expressions
Summary:
Constant evaluator does not work on value-dependent or type-dependent
expressions.

Also fixed bugs uncovered by these assertions.

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61522

llvm-svn: 361050
2019-05-17 17:16:53 +00:00
Richard Smith 51ce8444f0 Fix crash if, during evaluation of __builtin_object_size, we try to load
through an invalid base.

llvm-svn: 360998
2019-05-17 08:01:34 +00:00
Richard Smith ee0ce302c5 Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

This reinstates r360974, reverted in r360988, with a fix for a
static_assert failure on 32-bit builds: force Type base class to have
8-byte alignment like the rest of Clang's AST nodes.

llvm-svn: 360995
2019-05-17 07:06:46 +00:00
Chris Bieneman a971003e46 Revert Refactor constant evaluation of typeid(T) to track a symbolic type_info object rather than tracking the originating expression.
This reverts r360974 (git commit 7ee4307bd4)

llvm-svn: 360988
2019-05-17 05:46:03 +00:00
Chris Bieneman a5a4124c49 Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic class type in constant evaluation.
This reverts r360977 (git commit f51dc8d2f9)

llvm-svn: 360987
2019-05-17 05:45:57 +00:00
Richard Smith f51dc8d2f9 [c++20] P1327R1: Support for typeid applied to objects of polymorphic
class type in constant evaluation.

llvm-svn: 360977
2019-05-17 02:16:45 +00:00
Richard Smith 7ee4307bd4 Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

llvm-svn: 360974
2019-05-17 01:46:05 +00:00
Eric Fiselier 708afb56c1 Implement __builtin_LINE() et. al. to support source location capture.
Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. 

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

Differential Revision: https://reviews.llvm.org/D37035

llvm-svn: 360937
2019-05-16 21:04:15 +00:00
Richard Smith 7bd54ab586 [c++20] For P1327R1: support dynamic_cast in constant expression
evaluation.

llvm-svn: 360806
2019-05-15 20:22:21 +00:00
Richard Smith 921f132a0f [c++20] P1064R0: Allow virtual function calls in constant expression
evaluation.

This reinstates r360559, reverted in r360580, with a fix to avoid
crashing if evaluation-for-overflow mode encounters a virtual call on an
object of a class with a virtual base class, and to generally not try to
resolve virtual function calls to objects whose (notional) vptrs are not
readable. (The standard rules are unclear here, but this seems like a
reasonable approach.)

llvm-svn: 360635
2019-05-13 23:35:21 +00:00
Hans Wennborg d5fb162563 Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant expression evaluation."
This caused Chromium builds to hit the new "can't handle virtual calls with
virtual bases" assert. Reduced repro coming up.

llvm-svn: 360580
2019-05-13 13:19:09 +00:00
Richard Smith dab287b550 PR41854: Don't assert when constant-evaluating a member function call on an invalid designator.
llvm-svn: 360560
2019-05-13 07:51:29 +00:00
Richard Smith 5c5be6b2f7 [c++20] P1064R0: Allow virtual function calls in constant expression
evaluation.

llvm-svn: 360559
2019-05-13 07:42:10 +00:00
Richard Smith debad6460b Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.

This reinstates r360499, reverted in r360531.

llvm-svn: 360538
2019-05-12 09:39:08 +00:00
Richard Smith d3d6f4f65c Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.

This reinstates r360464 (reverted in r360531) with a workaround for an
MSVC bug that previously caused the Windows bots to fail.

llvm-svn: 360537
2019-05-12 08:57:59 +00:00
Simon Pilgrim 73e8b67438 Revert rL360499 and rL360464 from cfe/trunk:
Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.
........
Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.
........
Fixes windows buildbots

llvm-svn: 360531
2019-05-11 20:21:59 +00:00
Richard Smith d05df0ef43 Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.

llvm-svn: 360499
2019-05-11 02:00:06 +00:00
Richard Smith c0fe5eb39c Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.

llvm-svn: 360464
2019-05-10 20:05:32 +00:00
Richard Smith 5b5e27afa4 Improve interface of APValuePathEntry.
llvm-svn: 360463
2019-05-10 20:05:31 +00:00
Fangrui Song c4f12013df Delete write-only HasQualifiers after rC360370
llvm-svn: 360408
2019-05-10 06:59:50 +00:00
Richard Smith d9c6b039db DR1872: don't allow any calls to virtual functions in constant
evaluation.

Not even in cases where we would not actually perform virtual dispatch.

llvm-svn: 360370
2019-05-09 19:45:49 +00:00
Richard Smith 37be3363b5 Disallow the operand of __builtin_constant_p from modifying enclosing
state when it's encountered while evaluating a constexpr function.

We attempt to follow GCC trunk's behavior here, but it is somewhat
inscrutible, so our behavior is only approximately the same for now.
Specifically, we only permit modification of objects whose lifetime
began within the operand of the __builtin_constant_p. GCC appears to
have effectively the same restriction, but also some unknown restriction
based on where and how the local state of the constexpr function is
mentioned within the operand (see added testcases).

llvm-svn: 359958
2019-05-04 04:00:45 +00:00
David Blaikie 639b3d1b83 Remove else-after-return
llvm-svn: 359913
2019-05-03 18:11:31 +00:00
Richard Smith f7d3048e5b Fix -Wunsequenced false-positives in code controlled by a branch on
__builtin_constant_p.

If the operand of __builtin_constant_p is not constant and has
side-effects, then code controlled by a branch on it is unreachable and
we should not emit runtime behavior warnings in such code.

llvm-svn: 359844
2019-05-02 23:21:28 +00:00
Richard Smith 31cfb311c5 Reinstate r359059, reverted in r359361, with a fix to properly prevent
us emitting the operand of __builtin_constant_p if it has side-effects.

Original commit message:

Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
  * Clang now supports nullptr_t as the argument type for
    __builtin_constant_p
    * Clang now returns true from __builtin_constant_p if called with a
    null pointer
    * Clang now returns true from __builtin_constant_p if called with an
    integer cast to pointer type

llvm-svn: 359367
2019-04-27 02:58:17 +00:00
Jorge Gorbe Moya 1dbd42ab5b Revert Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC.
This reverts r359059 (git commit 0b098754b7)

llvm-svn: 359361
2019-04-27 00:32:04 +00:00
Eric Fiselier add16a8da9 [Builtins] Implement __builtin_is_constant_evaluated for use in C++2a
Summary:
This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`.

More tests to come, but early feedback is appreciated.

I plan to implement warnings for common mis-usages like those belowe in a following patch:
```
void foo(int x) {
  if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead.
   foo_constexpr(x);
  } else {
    foo_runtime(x);
  }
}
```



Reviewers: rsmith, MaskRay, bruno, void

Reviewed By: rsmith

Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits

Differential Revision: https://reviews.llvm.org/D55500

llvm-svn: 359067
2019-04-24 02:23:30 +00:00
Richard Smith 0b098754b7 Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
 * Clang now supports nullptr_t as the argument type for
   __builtin_constant_p
 * Clang now returns true from __builtin_constant_p if called with a
   null pointer
 * Clang now returns true from __builtin_constant_p if called with an
   integer cast to pointer type

llvm-svn: 359059
2019-04-24 01:29:28 +00:00
Eric Fiselier 680e865c31 [8.0 Regression] Fix handling of `__builtin_constant_p` inside template arguments, enumerators, case statements, and the enable_if attribute.
Summary:
The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1]

```
// error {{never produces a constant expression}}
void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {}
void test() { foo("abc"); }
```

Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression.

The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions.

[1]  https://godbolt.org/z/ksAjmq

Reviewers: rsmith, hans, sbenza

Reviewed By: rsmith

Subscribers: kristina, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D59038

llvm-svn: 355743
2019-03-08 22:06:48 +00:00
Akira Hatanaka 1488ee4bd5 [ObjC] Emit a boxed expression as a compile-time constant if the
expression inside the parentheses is a valid UTF-8 string literal.

Previously clang emitted an expression like @("abc") as a message send
to stringWithUTF8String. This commit makes clang emit the boxed
expression as a compile-time constant instead.

This commit also has the effect of silencing the nullable-to-nonnull
conversion warning clang started emitting after r317727, which
originally motivated this commit (see https://oleb.net/2018/@keypath).

rdar://problem/42684601

Differential Revision: https://reviews.llvm.org/D58729

llvm-svn: 355662
2019-03-08 04:45:37 +00:00
Hans Wennborg dd1ea8abb7 Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)
Apparently GCC allows this, and there's code relying on it (see bug).

The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be done
(the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()).

Differential Revision: https://reviews.llvm.org/D58821

llvm-svn: 355491
2019-03-06 10:26:19 +00:00
Leonard Chan 8f7caae00a [Fixed Point Arithmetic] Fixed Point and Integer Conversions
This patch includes the necessary code for converting between a fixed point type and integer.
This also includes constant expression evaluation for conversions with these types.

Differential Revision: https://reviews.llvm.org/D56900

llvm-svn: 355462
2019-03-06 00:28:43 +00:00
Leonard Chan ce1d4f1bec [Fixed Point Arithmetic] Fixed Point Comparisons
This patch implements fixed point comparisons with other fixed point types and
integers. This also provides constant expression evaluation for them.

Differential Revision: https://reviews.llvm.org/D57219

llvm-svn: 354621
2019-02-21 20:50:09 +00:00
Clement Courbet 8c3343dfd5 [Builtins] Treat `bcmp` as a builtin.
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.

Also see the discussion in https://reviews.llvm.org/D56593.

Reviewers: jyknight

Subscribers: kristina, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58120

llvm-svn: 354023
2019-02-14 12:00:34 +00:00
Eli Friedman 041adb0ed0 Fix buildbot failure from r353569.
I assumed lvalue-to-rvalue conversions of array type would never
happen, but apparently clang-tidy tries in some cases.

llvm-svn: 353598
2019-02-09 02:22:17 +00:00
Eli Friedman 3bf72d7d64 [Sema] Make string literal init an rvalue.
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.

This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization.  If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray.  This shouldn't
affect the memory usage for other string literals.  (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)

The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check.  I this this is fine.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .

llvm-svn: 353569
2019-02-08 21:18:46 +00:00
Erik Pilkington 9c3b588db9 Add a new builtin: __builtin_dynamic_object_size
This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:

  void f(size_t alloc) {
    char* p = malloc(alloc);
    strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
  }

This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.

rdar://32212419

Differential revision: https://reviews.llvm.org/D56760

llvm-svn: 352665
2019-01-30 20:34:53 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Leonard Chan d3f3e16293 [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation
This patch includes logic for constant expression evaluation of fixed point additions.

Differential Revision: https://reviews.llvm.org/D55868

llvm-svn: 351593
2019-01-18 21:04:25 +00:00
Leonard Chan 86285d2e17 [Fixed Point Arithmetic] Add APFixedPoint to APValue
This adds APFixedPoint to the union of values that can be represented with an APValue.

Differential Revision: https://reviews.llvm.org/D56746

llvm-svn: 351368
2019-01-16 18:53:05 +00:00
Brian Gesiak 5488ab4ddd [AST] Remove ASTContext from getThisType (NFC)
Summary:
https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from
within the `CXXMethodDecl::getThisType` method. Remove the parameter
altogether, as well as all usages of it. This does not result in any
functional change because the parameter was unused since
https://reviews.llvm.org/D54862.

Test Plan: check-clang

Reviewers: akyrtzi, mikael

Reviewed By: mikael

Subscribers: mehdi_amini, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D56509

llvm-svn: 350914
2019-01-11 01:54:53 +00:00
Tan S. B. 9f935e8749 [ExprConstant] Handle compound assignment when LHS has integral type and RHS has floating point type
Fixes PR39858

Differential Revision: https://reviews.llvm.org/D55413

llvm-svn: 349444
2018-12-18 07:38:06 +00:00
Eric Fiselier 261875054e [Clang] Add __builtin_launder
Summary:
This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC.

I'm not exactly sure what magic `__builtin_launder` requires, but  based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables.

Reviewers: rnk, majnemer, rsmith

Reviewed By: rsmith

Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek

Differential Revision: https://reviews.llvm.org/D40218

llvm-svn: 349195
2018-12-14 21:11:28 +00:00
Hubert Tong 147b743602 [ExprConstant] Improve memchr/memcmp for type mismatch and multibyte element types
Summary:
`memchr` and `memcmp` operate upon the character units of the object
representation; that is, the `size_t` parameter expresses the number of
character units. The constant folding implementation is updated in this
patch to account for multibyte element types in the arrays passed to
`memchr`/`memcmp` and, in the case of `memcmp`, to account for the
possibility that the arrays may have differing element types (even when
they are byte-sized).

Actual inspection of the object representation is not implemented.
Comparisons are done only between elements with the same object size;
that is, `memchr` will fail when inspecting at least one character unit
of a multibyte element. The integer types are assumed to have two's
complement representation with 0 for `false`, 1 for `true`, and no
padding bits.

`memcmp` on multibyte elements will only be able to fold in cases where
enough elements are equal for the answer to be 0.

Various tests are added to guard against incorrect folding for cases
that miscompile on some system or other prior to this patch. At the same
time, the unsigned 32-bit `wchar_t` testing in
`test/SemaCXX/constexpr-string.cpp` is restored.

Reviewers: rsmith, aaron.ballman, hfinkel

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D55510

llvm-svn: 348938
2018-12-12 16:53:43 +00:00
Bruno Cardoso Lopes 5c1399a582 [constexpr][c++2a] Try-catch blocks in constexpr functions
Implement support for try-catch blocks in constexpr functions, as
proposed in http://wg21.link/P1002 and voted in San Diego for c++20.

The idea is that we can still never throw inside constexpr, so the catch
block is never entered. A try-catch block like this:

try { f(); } catch (...) { }

is then morally equivalent to just

{ f(); }

Same idea should apply for function/constructor try blocks.

rdar://problem/45530773

Differential Revision: https://reviews.llvm.org/D55097

llvm-svn: 348789
2018-12-10 19:03:12 +00:00
Raphael Isemann b23ccecbb0 Misc typos fixes in ./lib folder
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D55475

llvm-svn: 348755
2018-12-10 12:37:46 +00:00
Bill Wendling 2a81f6670d Specify constant context in constant emitter
The constant emitter may need to evaluate the expression in a constant context.
For exasmple, global initializer lists.

llvm-svn: 348070
2018-12-01 08:29:36 +00:00
Fangrui Song 407659ab0a Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""
It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now

llvm-svn: 348053
2018-11-30 23:41:18 +00:00
Fangrui Song f5d3335d75 Revert r347417 "Re-Reinstate 347294 with a fix for the failures."
Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:

  extern char extern_var;
  struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348039
2018-11-30 21:26:09 +00:00
Fangrui Song 81a1a8e181 [ExprConstant] Try fixing __builtin_constant_p after D54355 (rC347417)
Summary:
Reinstate the original behavior (Success(false, E)) before D54355 when this branch is
taken. This fixes spurious error of the following snippet:

  extern char extern_var;
  struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348037
2018-11-30 21:15:41 +00:00
Hans Wennborg 48ee4ad325 Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."
This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.

llvm-svn: 347756
2018-11-28 14:04:12 +00:00
Hans Wennborg 8c79706e89 Revert r347417 "Re-Reinstate 347294 with a fix for the failures."
This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

  static bool f(int *a, int *b) {
    return !__builtin_constant_p(b - a) || (!(b - a));
  }

  int arr[] = {1,2,3};

  bool g() {
    return f(arr, arr + 3);
  }

  $ clang -O2 -S -emit-llvm a.cc -o -

g() should return true, but after r347417 it became false for some reason.

This also reverts the follow-up commits.

r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!

r347446:
> The result of is.constant() is unsigned.

r347480:
> A __builtin_constant_p() returns 0 with a function type.

r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.

r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347656
2018-11-27 14:01:40 +00:00
Bill Wendling 372b1e796b A "constexpr" is evaluated in a constant context. Make sure this is reflected
if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347531
2018-11-26 02:10:53 +00:00
Bill Wendling 1af8dd6a1e isEvaluatable() implies a constant context.
Assume that we're in a constant context if we're asking if the expression can
be compiled into a constant initializer. This fixes the issue where a
__builtin_constant_p() in a compound literal was diagnosed as not being
constant, even though it's always possible to convert the builtin into a
constant.

llvm-svn: 347512
2018-11-24 10:45:55 +00:00
Bill Wendling 6ff1751f7d Re-Reinstate 347294 with a fix for the failures.
Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().

Third time's a charm!

llvm-svn: 347417
2018-11-21 20:44:18 +00:00
Nico Weber 9f0246d473 Revert r347364 again, the fix was incomplete.
llvm-svn: 347389
2018-11-21 12:47:43 +00:00
Bill Wendling 91549ed15f Reinstate 347294 with a fix for the failures.
EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.

llvm-svn: 347364
2018-11-20 23:24:16 +00:00
Nico Weber 6438972553 Revert 347294, it turned many bots on lab.llvm.org:8011/console red.
llvm-svn: 347314
2018-11-20 15:27:43 +00:00
Bill Wendling 107b0e9881 Use is.constant intrinsic for __builtin_constant_p
Summary:
A __builtin_constant_p may end up with a constant after inlining. Use
the is.constant intrinsic if it's a variable that's in a context where
it may resolve to a constant, e.g., an argument to a function after
inlining.

Reviewers: rsmith, shafik

Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight

Differential Revision: https://reviews.llvm.org/D54355

llvm-svn: 347294
2018-11-20 08:53:30 +00:00
Richard Smith bd844e0de7 PR39628 Treat all non-zero values as 'true' in bool compound-assignment
in constant evaluation, not just odd values.

llvm-svn: 346699
2018-11-12 20:11:57 +00:00
Bill Wendling 8003edc9aa Compound literals, enums, et al require const expr
Summary:
Compound literals,  enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.

Reviewers: rsmith, shafik

Reviewed By: rsmith

Subscribers: cfe-commits, jyknight, nickdesaulniers

Differential Revision: https://reviews.llvm.org/D53921

llvm-svn: 346455
2018-11-09 00:41:36 +00:00
Andrew Savonichev 3fee351867 [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension
Summary:
Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt

Patch by Kristina Bessonova


Reviewers: Anastasia, yaxunl, shafik

Reviewed By: Anastasia

Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits

Differential Revision: https://reviews.llvm.org/D51484

llvm-svn: 346392
2018-11-08 11:25:41 +00:00
Andrew Savonichev 3b12b7e702 Revert r346326 [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation
This patch breaks Index/opencl-types.cl LIT test:

Script:
--
: 'RUN: at line 1';   stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl
--
Command Output (stderr):
--
llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed
llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled

llvm-svn: 346338
2018-11-07 18:34:19 +00:00
Andrew Savonichev 35dfce723c [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension
Summary:
Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt

Patch by Kristina Bessonova


Reviewers: Anastasia, yaxunl, shafik

Reviewed By: Anastasia

Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits

Differential Revision: https://reviews.llvm.org/D51484

llvm-svn: 346326
2018-11-07 15:44:01 +00:00
Tim Northover 314fbfa1c4 Reapply Logging: make os_log buffer size an integer constant expression.
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.

This also moves the OSLog and other FormatString helpers from
libclangAnalysis to libclangAST to avoid a circular dependency.

llvm-svn: 345971
2018-11-02 13:14:11 +00:00
Tim Northover eedc0f0f1a Revert "Reapply Logging: make os_log buffer size an integer constant expression."
Still more dependency hell.

llvm-svn: 345871
2018-11-01 18:37:42 +00:00
Tim Northover c1ac697ab7 Reapply Logging: make os_log buffer size an integer constant expression.
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.

This also moves the OSLog helpers from libclangAnalysis to libclangAST
to avoid a circular dependency.

llvm-svn: 345866
2018-11-01 18:04:49 +00:00
Reid Kleckner e540d97b10 Replace two fallthrough annotations after covered switch with unreachable
Both preceding switches handle all possible enumerators, so the
fallthrough is actually unreachable. This strengthens that to an
assertion.

The first instance had a comment from 2010 indicating that fallthrough
was possible, but that was back when we had a unary operator for
offsetof. Now it is its own expression kind, so the annotation was
stale.

llvm-svn: 345862
2018-11-01 17:51:48 +00:00
Tim Northover d686dbbc7c Revert "Logging: make os_log buffer size an integer constant expression.
This also reverts a couple of follow-up commits trying to fix the
dependency issues. Latest revision added a cyclic dependency that can't
just be patched up in 5 minutes.

llvm-svn: 345846
2018-11-01 16:15:24 +00:00
Tim Northover a94ecc619b Logging: make os_log buffer size an integer constant expression.
The size of an os_log buffer is known at any stage of compilation, so making it
a constant expression means that the common idiom of declaring a buffer for it
won't result in a VLA. That allows the compiler to skip saving and restoring
the stack pointer around such buffers.

llvm-svn: 345828
2018-11-01 13:49:54 +00:00
Bill Wendling 7c44da279e Create ConstantExpr class
A ConstantExpr class represents a full expression that's in a context where a
constant expression is required. This class reflects the path the evaluator
took to reach the expression rather than the syntactic context in which the
expression occurs.

In the future, the class will be expanded to cache the result of the evaluated
expression so that it's not needlessly re-evaluated

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D53475

llvm-svn: 345692
2018-10-31 03:48:47 +00:00
Richard Smith 6822bd79ac PR26547: alignof should return ABI alignment, not preferred alignment
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof

Patch by Nicole Mazzuca!

Differential Revision: https://reviews.llvm.org/D53207

llvm-svn: 345419
2018-10-26 19:26:45 +00:00
Leonard Chan b4ba467da8 [Fixed Point Arithmetic] Fixed Point to Boolean Cast
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split
the casting logic up into smaller patches. This contains the code for casting
from fixed point types to boolean types.

Differential Revision: https://reviews.llvm.org/D53308

llvm-svn: 345063
2018-10-23 17:55:35 +00:00
Andrew Savonichev b555b76ed3 [OpenCL][NFC] Unify ZeroToOCL* cast types
Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: asavonic, cfe-commits

Differential Revision: https://reviews.llvm.org/D52654

llvm-svn: 345038
2018-10-23 15:19:20 +00:00
David Bolvansky 3b6ae57654 [Diagnostics] Check for integer overflow in array size expressions
Summary: Fixes PR27439

Reviewers: rsmith, Rakete1111

Reviewed By: rsmith

Subscribers: Rakete1111, cfe-commits

Differential Revision: https://reviews.llvm.org/D52750

llvm-svn: 344759
2018-10-18 20:49:06 +00:00
Leonard Chan 99bda375a1 [Fixed Point Arithmetic] FixedPointCast
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other fixed point types.

The method for converting between fixed point types is based off the convert()
method in APFixedPoint.

Differential Revision: https://reviews.llvm.org/D50616

llvm-svn: 344530
2018-10-15 16:07:02 +00:00
James Y Knight 892b09ba11 ExprConstant: Make __builtin_object_size use EM_IgnoreSideEffects.
And, since EM_OffsetFold is now unused, remove it.

While builtin_object_size intends to ignore the presence of
side-effects in its argument, the EM_OffsetFold mode was NOT
configured to ignore side-effects. Rather it was effectively identical
to EM_ConstantFold -- its explanatory comment
notwithstanding.

However, currently, keepEvaluatingAfterSideEffect() is not always
honored -- sometimes evaluation continues despite it returning
false. Therefore, since the b_o_s code was only checking the return
value from evaluation, and not additionally checking the
HasSideEffects flag, side-effects _were_ in many cases actually being
ignored.

This change is a prerequisite cleanup towards fixing that issue.

Differential Revision: https://reviews.llvm.org/D52924

llvm-svn: 344110
2018-10-10 02:53:43 +00:00
James Y Knight 49bf370a8b Emit CK_NoOp casts in C mode, not just C++.
Previously, it had been using CK_BitCast even for casts that only
change const/restrict/volatile. Now it will use CK_Noop where
appropriate.

This is an alternate solution to r336746.

Differential Revision: https://reviews.llvm.org/D52918

llvm-svn: 343892
2018-10-05 21:53:51 +00:00
James Y Knight c7d3e609fb Emit diagnostic note when calling an invalid function declaration.
The comment said it was intentionally not emitting any diagnostic
because the declaration itself was already diagnosed. However,
everywhere else that wants to not emit a diagnostic without an extra
note emits note_invalid_subexpr_in_const_expr instead, which gets
suppressed later.

This was the only place which did not emit a diagnostic note.

Differential Revision: https://reviews.llvm.org/D52919

llvm-svn: 343867
2018-10-05 17:49:48 +00:00
Petr Pavlu ed083f2c1f [constexpr] Fix ICE when memcpy() is given a pointer to an incomplete array
Fix code for constant evaluation of __builtin_memcpy() and
__builtin_memmove() that would attempt to divide by zero when given two
pointers to an incomplete array.

Differential Revision: https://reviews.llvm.org/D51855

llvm-svn: 343761
2018-10-04 09:25:44 +00:00
Richard Smith 8baa50013c [cxx2a] P0614R1: Support init-statements in range-based for loops.
We don't yet support this for the case where a range-based for loop is
implicitly rewritten to an ObjC for..in statement.

llvm-svn: 343350
2018-09-28 18:44:09 +00:00
Richard Smith 128719c4fe Fix crash on call to __builtin_memcpy with a null pointer to an
incomplete type.

Also improve the diagnostics for similar situations.

llvm-svn: 342192
2018-09-13 22:47:33 +00:00
Stephen Kelly 1c301dcbc4 Port getLocEnd -> getEndLoc
Reviewers: teemperor!

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D50351

llvm-svn: 339386
2018-08-09 21:09:38 +00:00
Stephen Kelly f2ceec4811 Port getLocStart -> getBeginLoc
Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D50350

llvm-svn: 339385
2018-08-09 21:08:08 +00:00
Craig Topper f95a6d9305 [Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExpr
This addresses a FIXME that has existed since before clang supported the builtin.

This time with only reviewed changes.

Differential Revision: https://reviews.llvm.org/D50471

llvm-svn: 339295
2018-08-08 22:31:12 +00:00
Craig Topper 3e8820a01e Revert r339287 "[Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExpr"
This add an additional unintended change in it.

llvm-svn: 339289
2018-08-08 21:21:21 +00:00
Craig Topper 9ff024a54f [Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExpr
This addresses a FIXME that has existed since before clang supported the builtin.

Differential Revision: https://reviews.llvm.org/D50471

llvm-svn: 339287
2018-08-08 20:59:40 +00:00
Leonard Chan c03642e9a8 [Fixed Point Arithmetic] Fix for FixedPointValueToString
- Print negative numbers correctly
- Handle APInts of different sizes
- Add formal unit tests for FixedPointValueToString
- Add tests for checking correct printing when padding is set
- Restrict to printing in radix 10 since that's all we need for now

Differential Revision: https://reviews.llvm.org/D49945

llvm-svn: 339026
2018-08-06 16:05:08 +00:00
Richard Smith 06f71b5bd8 [constexpr] Support for constant evaluation of __builtin_memcpy and
__builtin_memmove (in non-type-punning cases).

This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.

__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.

This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.

llvm-svn: 338941
2018-08-04 00:57:17 +00:00
Hans Wennborg 6bd4f924e7 Revert r338455 "[constexpr] Support for constant evaluation of __builtin_memcpy and __builtin_memmove (in non-type-punning cases)."
It caused asserts during Chromium builds, see reply on the cfe-commits thread.

> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.

llvm-svn: 338602
2018-08-01 17:51:23 +00:00
Richard Smith 96beffba15 [constexpr] Support for constant evaluation of __builtin_memcpy and
__builtin_memmove (in non-type-punning cases).

This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.

__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.

llvm-svn: 338455
2018-07-31 23:35:09 +00:00
Fangrui Song 6907ce2f8f Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291
2018-07-30 19:24:48 +00:00
Erich Keane 1ddd4bf87f Prevent Scoped Enums from being Integral constant expressions:
Discovered because of: https://bugs.llvm.org/show_bug.cgi?id=38235

It seems to me that a scoped enum should NOT be an integral constant expression
without a cast, so this seems like a sensical change.

Attributes that check for an integer parameter simply use this function to
ensure that they have an integer, so it was previously allowing a scoped enum.

Also added a test based on Richard's feedback to ensure that case labels still work.

Differential Revision: https://reviews.llvm.org/D49599

llvm-svn: 337585
2018-07-20 17:42:09 +00:00
Richard Smith 81dfef9202 PR38095: Allow constant-folding of loads through bitcasted pointers if
the bitcast only changed cvr-qualifications within the pointer type.

llvm-svn: 336746
2018-07-11 00:29:05 +00:00
Erich Keane cb54964f80 Fix __builtin_*_overflow when out-param isn't constexpr
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

llvm-svn: 336364
2018-07-05 15:52:58 +00:00
Leonard Chan db01c3adc6 [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals
This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal.

Fixed point literals are declared using the suffixes

```
hr: short _Fract
uhr: unsigned short _Fract
r: _Fract
ur: unsigned _Fract
lr: long _Fract
ulr: unsigned long _Fract
hk: short _Accum
uhk: unsigned short _Accum
k: _Accum
uk: unsigned _Accum
```
Errors are also thrown for illegal literal values

```
unsigned short _Accum u_short_accum = 256.0uhk;   // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
```

Differential Revision: https://reviews.llvm.org/D46915

llvm-svn: 335148
2018-06-20 17:19:40 +00:00
Leonard Chan ab80f3c8b7 [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents
This diff includes changes for the remaining _Fract and _Sat fixed point types.

```
signed short _Fract s_short_fract;
signed _Fract s_fract;
signed long _Fract s_long_fract;
unsigned short _Fract u_short_fract;
unsigned _Fract u_fract;
unsigned long _Fract u_long_fract;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
short _Fract short_fract;
_Fract fract;
long _Fract long_fract;

// Saturated fixed point types
_Sat signed short _Accum sat_s_short_accum;
_Sat signed _Accum sat_s_accum;
_Sat signed long _Accum sat_s_long_accum;
_Sat unsigned short _Accum sat_u_short_accum;
_Sat unsigned _Accum sat_u_accum;
_Sat unsigned long _Accum sat_u_long_accum;
_Sat signed short _Fract sat_s_short_fract;
_Sat signed _Fract sat_s_fract;
_Sat signed long _Fract sat_s_long_fract;
_Sat unsigned short _Fract sat_u_short_fract;
_Sat unsigned _Fract sat_u_fract;
_Sat unsigned long _Fract sat_u_long_fract;

// Aliased saturated fixed point types
_Sat short _Accum sat_short_accum;
_Sat _Accum sat_accum;
_Sat long _Accum sat_long_accum;
_Sat short _Fract sat_short_fract;
_Sat _Fract sat_fract;
_Sat long _Fract sat_long_fract;
```

This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches.

Differential Revision: https://reviews.llvm.org/D46911

llvm-svn: 334718
2018-06-14 14:53:51 +00:00
Erich Keane 00958270aa Implement constexpr __builtin_*_overflow
As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
permit the __builtin_*_overflow builtins in constexpr functions.

Differential Revision: https://reviews.llvm.org/D48040

llvm-svn: 334650
2018-06-13 20:43:27 +00:00
Leonard Chan f921d85422 This diff includes changes for supporting the following types.
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.

The tests included are for asserting that we can declare these types.

Fixed the test that was failing by not checking for dso_local on some
targets.

Differential Revision: https://reviews.llvm.org/D46084

llvm-svn: 333923
2018-06-04 16:07:52 +00:00
Leonard Chan 0d485dbb40 Revert "This diff includes changes for supporting the following types."
This reverts commit r333814, which fails for a test checking the bit
width on ubuntu.

llvm-svn: 333815
2018-06-02 03:27:13 +00:00
Leonard Chan db55d8331e This diff includes changes for supporting the following types.
```

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;

```

This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.

The tests included are for asserting that we can declare these types.

Differential Revision: https://reviews.llvm.org/D46084

llvm-svn: 333814
2018-06-02 02:58:51 +00:00
Richard Smith 08b682bec1 Rework __builtin_classify_type support to better match GCC and to not assert on
unusual types.

Following the observed behavior of GCC, we now return -1 for vector types
(along with all of our extensions that GCC doesn't support), and for atomic
types we classify the underlying type.

GCC appears to have changed its classification for function and array arguments
between version 5 and version 6. Previously it would classify them as pointers
in C and as functions or arrays in C++, but from version 6 onwards, it
classifies them as pointers. We now follow the more recent GCC behavior rather
than emulating what I can only assume to be a historical bug in their C++
support for this builtin.

Finally, no version of GCC that I can find has ever used the "method"
classification for C++ pointers to member functions. Instead, GCC classifies
them as record types, presumably reflecting an internal implementation detail,
but whatever the reason we now produce compatible results.

llvm-svn: 333126
2018-05-23 21:18:00 +00:00
Richard Smith 3f1d6de4f7 Revert r332847; it caused us to miscompile certain forms of reference initialization.
llvm-svn: 332886
2018-05-21 20:36:58 +00:00
Serge Pavlov 9f8068420a [CodeGen] Recognize more cases of zero initialization
If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
resources. It causes strange behavior from user viewpoint: compilation
of huge zero initialized arrays like:

    char data_1[2147483648u] = { 0 };

consumes enormous amount of time and memory.

With this change codegen tries to determine if variable initializer is
equivalent to zero initializer. In this case variable value is not
constructed.

This change fixes PR18978.

Differential Revision: https://reviews.llvm.org/D46241

llvm-svn: 332847
2018-05-21 16:09:54 +00:00
Nicola Zaghen 3538b39ed5 [clang] Update uses of DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM

Explicitly avoided changing the strings in the clang-format tests.

Differential Revision: https://reviews.llvm.org/D44975

llvm-svn: 332350
2018-05-15 13:30:56 +00:00
Reid Kleckner 1a840d29b4 Allow dllimport non-type template arguments in C++17
Summary:
Fixes PR35772.

Reviewers: rsmith

Differential Revision: https://reviews.llvm.org/D43320

llvm-svn: 332018
2018-05-10 18:57:35 +00:00
Adrian Prantl 9fc8faf9e6 Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46320

llvm-svn: 331834
2018-05-09 01:00:01 +00:00
Simon Pilgrim 3366dcfe1f Fix 'not all control paths return a value' MSVC warnings. NFCI.
llvm-svn: 331753
2018-05-08 09:40:32 +00:00
Eric Fiselier 0683c0e68d [C++2a] Implement operator<=> CodeGen and ExprConstant
Summary:
This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback.

The main changes are:

* Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes. 

* Implement [expr.spaceship] checking, including diagnosing narrowing conversions. 

* Implement `ExprConstant` for builtin spaceship operators.

* Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp.

* Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround.




Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall

Reviewed By: rjmccall

Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D45476

llvm-svn: 331677
2018-05-07 21:07:10 +00:00
Richard Smith 3a8244df6f Implement P0482R2, support for char8_t type.
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)

This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.

llvm-svn: 331244
2018-05-01 05:02:45 +00:00
Benjamin Kramer 33b7092601 [AST] strcmp/memcmp always compares unsigned chars.
This makes it return the right result in a couple of edge cases. The
wide versions always do the comparison on the underlying wchar_t type.

llvm-svn: 330656
2018-04-23 22:04:34 +00:00
Malcolm Parsons fab3680990 Clean carriage returns from lib/ and include/. NFC.
Summary:
Clean carriage returns from lib/ and include/. NFC.
(I have to make this change locally in order for `git diff` to show sane output after I edit a file, so I might as well ask for it to be committed. I don't have commit privs myself.)
(Without this patch, `git rebase`ing any change involving SemaDeclCXX.cpp is a real nightmare. :( So while I have no right to ask for this to be committed, geez would it make my workflow easier if it were.)

Here's the command I used to reformat things. (Requires bash and OSX/FreeBSD sed.)

    git grep -l $'\r' lib include | xargs sed -i -e $'s/\r//'
    find lib include -name '*-e' -delete

Reviewers: malcolm.parsons

Reviewed By: malcolm.parsons

Subscribers: emaste, krytarowski, cfe-commits

Differential Revision: https://reviews.llvm.org/D45591

Patch by Arthur O'Dwyer.

llvm-svn: 330112
2018-04-16 08:31:08 +00:00
Akira Hatanaka 4e2698ca9e [ExprConstant] Use an AST node and a version number as a key to create
an APValue and retrieve it from map Temporaries.

The version number is needed when a single AST node is visited multiple
times and is used to create APValues that are required to be distinct
from each other (for example, MaterializeTemporaryExprs in default
arguments and VarDecls in loops).

rdar://problem/36505742

Differential Revision: https://reviews.llvm.org/D42776

llvm-svn: 329671
2018-04-10 05:15:01 +00:00
Manoj Gupta 4b3eefa5e8 Disable -fmerge-all-constants as default.
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).

Fixes PR18538.

Reviewers: rjmccall, rsmith, chandlerc

Reviewed By: rsmith, chandlerc

Subscribers: srhines, cfe-commits

Differential Revision: https://reviews.llvm.org/D45289

llvm-svn: 329300
2018-04-05 15:29:52 +00:00
Erik Pilkington 11232912b1 [AST] Don't track lambda captures when checking a potential constant expression.
Fixes PR36054.

Differential revision: https://reviews.llvm.org/D45194

llvm-svn: 329244
2018-04-05 00:12:05 +00:00
Joel E. Denny 8150810556 Reland "[Attr] Fix parameter indexing for several attributes"
Relands r326602 (reverted in r326862) with new test and fix for
PR36620.

Differential Revision: https://reviews.llvm.org/D43248

llvm-svn: 327405
2018-03-13 14:51:22 +00:00
Richard Smith 69cf59ed26 PR36645: Go looking for an appropriate array bound when constant-evaluating a
name of an array object.

llvm-svn: 327099
2018-03-09 02:00:01 +00:00
George Burgess IV 4763876f4b Reland r326766 (with a slightly modified test)
The original revert was done in r326869, since reverting r326602 broke
the test added by this.

The new test should be less dependent on r326602.

llvm-svn: 326872
2018-03-07 04:52:34 +00:00
Nico Weber b2ecd46ae4 Revert 326766 too, after r326862 the test fails and I don't know how to fix.
llvm-svn: 326869
2018-03-07 03:00:25 +00:00
Nico Weber bbf648253d Revert r326602, it caused PR36620.
llvm-svn: 326862
2018-03-07 02:22:41 +00:00
George Burgess IV 9753b7903d [ExprConstant] Look through ExprWithCleanups for `allocsize`
llvm-svn: 326766
2018-03-06 07:42:36 +00:00
Joel E. Denny 4925445958 [Attr] Fix parameter indexing for several attributes
The patch fixes a number of bugs related to parameter indexing in
attributes:

* Parameter indices in some attributes (argument_with_type_tag,
  pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
  and ownership_returns) are specified in source as one-origin
  including any C++ implicit this parameter, were stored as
  zero-origin excluding any this parameter, and were erroneously
  printing (-ast-print) and confusingly dumping (-ast-dump) as the
  stored values.

* For alloc_size, the C++ implicit this parameter was not subtracted
  correctly in Sema, leading to assert failures or to silent failures
  of __builtin_object_size to compute a value.

* For argument_with_type_tag, pointer_with_type_tag, and
  ownership_returns, the C++ implicit this parameter was not added
  back to parameter indices in some diagnostics.

This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes.  ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed.  Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*].  This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument.  The only exception is xray_log_args's
argument, which is encoded as a count not an index.

Differential Revision: https://reviews.llvm.org/D43248

llvm-svn: 326602
2018-03-02 19:03:22 +00:00
George Burgess IV 00f70bd933 Remove redundant casts. NFC
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.

Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).

I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.

llvm-svn: 326416
2018-03-01 05:43:23 +00:00
Volodymyr Sapsai e8f1ffb50a [ExprConstant] Fix crash when initialize an indirect field with another field.
When indirect field is initialized with another field, you have
MemberExpr with CXXThisExpr that corresponds to the field's immediate
anonymous parent. But 'this' was referring to the non-anonymous parent.
So when we were building LValue Designator, it was incorrect as it had
wrong starting point. Usage of such designator would cause unexpected
APValue changes and crashes.

The fix is in adjusting 'this' for indirect fields from non-anonymous
parent to the field's immediate parent.

Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4985

rdar://problem/36359187

Reviewers: rsmith, efriedma

Reviewed By: rsmith

Subscribers: cfe-commits, jkorous-apple

Differential Revision: https://reviews.llvm.org/D42498

llvm-svn: 325997
2018-02-23 23:59:20 +00:00
Richard Smith 9defb7d6b1 In C++14 onwards, it is permitted to read mutable members in constant
expressions, if their lifetime began during the evaluation of the expression.

This is technically not allowed in C++11, though we could consider permitting
it there too, as an extension.

llvm-svn: 325663
2018-02-21 03:38:30 +00:00
Ivan A. Kosarev 01df519f7e [AST] Refine the condition for element-dependent array fillers
This patch fixes clang to not consider braced initializers for
aggregate elements of arrays to be potentially dependent on the
indices of the initialized elements. Resolves bug 18978:
initialize a large static array = clang oom?
https://bugs.llvm.org/show_bug.cgi?id=18978

Differential Revision: https://reviews.llvm.org/D43187

llvm-svn: 325120
2018-02-14 13:10:35 +00:00
Aaron Ballman a503855906 Track in the AST whether the operand to a UnaryOperator can overflow and then use that logic when evaluating constant expressions and emitting codegen.
llvm-svn: 322074
2018-01-09 13:07:03 +00:00
Benjamin Kramer dfecbe9ad8 Add support for a limited subset of TS 18661-3 math builtins.
These just overloads for _Float128. They're supported by GCC 7 and used
by glibc. APFloat support is already there so just add the overloads.

__builtin_copysignf128
__builtin_fabsf128
__builtin_huge_valf128
__builtin_inff128
__builtin_nanf128
__builtin_nansf128

This is the same support that GCC has, according to the documentation,
but limited to _Float128.

llvm-svn: 321948
2018-01-06 21:49:54 +00:00
Alex Lorenz 4e246485a8 Fix an assertion failure regression in isDesignatorAtObjectEnd for
__builtin_object_size with incomplete array type in struct

The commit r316245 introduced a regression that causes an assertion failure when
Clang tries to cast an IncompleteArrayType to a PointerType when evaluating
__builtin_object_size.

rdar://36094951

Differential Revision: https://reviews.llvm.org/D41405

llvm-svn: 321222
2017-12-20 21:03:38 +00:00
Adrian Prantl f3b3ccda59 Silence a bunch of implicit fallthrough warnings
llvm-svn: 321115
2017-12-19 22:06:11 +00:00
Richard Smith c70f1d63f8 [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.

All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.

llvm-svn: 320707
2017-12-14 15:16:18 +00:00
Richard Smith efdb50375f PR35214: don't crash if we see an array of unknown bound added to an empty but invalid designator.
llvm-svn: 318258
2017-11-15 03:03:56 +00:00
Jordan Rose d4503da40c Unnamed bitfields don't block constant evaluation of constexpr ctors
C++14 [dcl.constexpr]p4 states that in the body of a constexpr
constructor,

> every non-variant non-static data member and base class sub-object
  shall be initialized

However, [class.bit]p2 notes that

> Unnamed bit-fields are not members and cannot be initialized.

Therefore, we should make sure to filter them out of the check that
all fields are initialized.

Fixing this makes the constant evaluator a bit smarter, and
specifically allows constexpr constructors to avoid tripping
-Wglobal-constructors when the type contains unnamed bitfields.

Reviewed at https://reviews.llvm.org/D39035.

llvm-svn: 316408
2017-10-24 02:17:07 +00:00
Richard Smith 6f4f0f1865 Implement current CWG direction for support of arrays of unknown bounds in
constant expressions.

We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).

This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.

This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.

llvm-svn: 316245
2017-10-20 22:56:25 +00:00
Jonas Hahnfeld 23604a8399 [OpenMP] Implement omp_is_initial_device() as builtin
This allows to return the static value that we know at compile time.

Differential Revision: https://reviews.llvm.org/D38968

llvm-svn: 316001
2017-10-17 14:28:14 +00:00
Erik Pilkington 4292549fb4 [ExprConstant] Allow constexpr ctor to modify non static data members
Fixes PR19741.

Differential revision: https://reviews.llvm.org/D38483

llvm-svn: 314865
2017-10-04 00:18:55 +00:00
Martin Bohme 542c84b2a1 Revert "Improve constant expression evaluation of arrays of unknown bound."
This reverts commit r311970.

Breaks internal tests.

llvm-svn: 312108
2017-08-30 10:44:46 +00:00
Richard Smith 2cd5604823 Improve constant expression evaluation of arrays of unknown bound.
The standard is not clear on how these are supposed to be handled, so we
conservatively treat as non-constant any cases whose value is unknown or whose
evaluation might result in undefined behavior.

llvm-svn: 311970
2017-08-29 01:52:13 +00:00
Richard Smith 7cd577bb0d PR34161: support evaluation of 'void()' expressions in C++14 onwards.
llvm-svn: 311115
2017-08-17 19:35:50 +00:00
Daniel Jasper a7e061f07b Fix undefined behavior that is caused by not always initializing a bool.
The fix in r310994 is incomplete, as moveFromAndCancel can set the
pointer without initializing OldIsSpeculativelyEvaluating.

llvm-svn: 311070
2017-08-17 06:33:46 +00:00
Chandler Carruth bacb80d0d9 Fix a UBSan failure where this boolean was copied when uninitialized.
When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.

llvm-svn: 310994
2017-08-16 07:22:49 +00:00
Reid Kleckner fdb3df65b6 Avoid PointerIntPair of constexpr EvalInfo structs
They are stack allocated, so their alignment is not to be trusted.
32-bit MSVC only guarantees 4 byte stack alignment, even though alignof
would tell you otherwise. I tried fixing this with __declspec align, but
that apparently upsets GCC. Hopefully this version will satisfy all
compilers.

See PR32018 for some info about the mingw issues.

Should supercede https://reviews.llvm.org/D34873

llvm-svn: 310905
2017-08-15 01:17:47 +00:00
Reid Kleckner cd016d8dc6 [MS] Don't statically initialize dllimport member function pointers
Summary:
r306137 made dllimport pointers to member functions non-constant. This
is correct because a load must be executed to resolve any dllimported
data. However, r306137 did not account for the use of dllimport member
function pointers used as template arguments.

This change re-lands r306137 with a template instantiation fix.

This fixes PR33570.

Reviewers: rnk, majnemer

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D34714

llvm-svn: 307446
2017-07-07 22:04:29 +00:00
Hiroshi Inoue 0c2734f8de fix trivial typos in comments; NFC
llvm-svn: 307123
2017-07-05 05:37:45 +00:00
Richard Smith 9f7df0c068 Revert r301742, which caused us to try to evaluate all full-expressions.
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.

This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.

Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.

llvm-svn: 306346
2017-06-26 23:19:32 +00:00
Reid Kleckner 33d501f7d1 Revert "[MS] Don't statically initialize dllimport member function pointers"
This reverts commit r306137. It has problems on code like this:

  struct __declspec(dllimport) Foo {
    int a;
    int get_a() { return a; }
  };
  template <int (Foo::*Getter)()> struct HasValue {
    int operator()(Foo *p) { return (p->*Getter)(); }
  };
  int main() {
    Foo f;
    f.a = 3;
    int x = HasValue<&Foo::get_a>()(&f);
  }

llvm-svn: 306175
2017-06-23 22:39:01 +00:00
Reid Kleckner 9c980cb502 [MS] Don't statically initialize dllimport member function pointers
We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130.  We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.

Fixes PR33570.

llvm-svn: 306137
2017-06-23 18:29:13 +00:00
Diana Picus bec724cbb0 Revert "Revert r301742 which made ExprConstant checking apply to all full-exprs."
This reverts commit r305239 because it broke the buildbots (the
diag-flags.cpp test is failing).

llvm-svn: 305287
2017-06-13 12:50:06 +00:00
Nick Lewycky 54992386f3 Revert r301742 which made ExprConstant checking apply to all full-exprs.
This patch also exposed pre-existing bugs in clang, see PR32864 and PR33140#c3 .

llvm-svn: 305239
2017-06-12 21:59:18 +00:00
Nick Lewycky 13073a6425 Revert r303316, a change to ExprConstant to evaluate function arguments.
The patch was itself correct but it uncovered other bugs which are going to be difficult to fix, per PR33140.

llvm-svn: 305233
2017-06-12 21:15:44 +00:00
Galina Kistanova f87496d107 Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.
llvm-svn: 304650
2017-06-03 06:31:42 +00:00
Tim Northover 0150333a3c Create valid LValue to represent null pointers in constant exprs
We were leaving the SubobjectDesignator in a surprising situation, where
it was allegedly valid but didn't actually refer to a type. This caused
a crash later on.

This patch fills out the SubobjectDesignator with the pointee type (as
happens in other evaluations of constant pointers) so that we don't
crash later.

llvm-svn: 303957
2017-05-26 02:16:00 +00:00
Nick Lewycky 9add1594d2 The constant expression evaluator should examine function arguments for non-constexpr function calls unless the EvalInfo says to stop.
llvm-svn: 303317
2017-05-17 23:56:54 +00:00
Daniel Jasper ffdee09350 Revert r301822 (and dependent r301825), which tried to improve the
handling of constexprs with unknown bounds.

This triggers a corner case of the language where it's not yet clear
whether this should be an error:

  struct A {
    static void *const a[];
    static void *const b[];
  };
  constexpr void *A::a[] = {&b[0]};
  constexpr void *A::b[] = {&a[0]};

When discovering the initializer for A::a, the bounds of A::b aren't known yet.
It is unclear whether warning about errors should be deferred until the end of
the translation unit, possibly resolving errors that can be resolved. In
practice, the compiler can know the bounds of all arrays in this example.

Credits for reproducers and explanation go to Richard Smith. Richard, please
add more info in case my explanation is wrong.

llvm-svn: 301963
2017-05-02 19:21:42 +00:00
Nick Lewycky c190f96b7d Revert r301785 (and r301787) because they caused PR32864.
The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form.

llvm-svn: 301891
2017-05-02 01:06:16 +00:00
Benjamin Kramer 5699969912 Silence unused variable warning. NFC.
llvm-svn: 301825
2017-05-01 20:00:23 +00:00
Richard Smith eec904f849 Improve handling of arrays of unknown bound in constant expressions.
Do not spuriously reject constexpr functions that access elements of an array
of unknown bound; this may later become valid once the bound is known. Permit
array-to-pointer decay on such arrays, but disallow pointer arithmetic (since
we do not know whether it will have defined behavior).

The standard is not clear on how this should work, but this seems to be a
decent answer.

Patch by Robert Haberlach!

llvm-svn: 301822
2017-05-01 18:49:04 +00:00
Nick Lewycky 499968f8a5 Handle expressions with non-literal types like ignored expressions if we are supposed to continue evaluating them.
Also fix a crash casting a derived nullptr to a virtual base.

llvm-svn: 301785
2017-05-01 02:03:23 +00:00
Nick Lewycky e7d6fbdfb7 Remove Sema::CheckForIntOverflow, and instead check all full-expressions.
CheckForIntOverflow used to implement a whitelist of top-level expressions to
send to the constant expression evaluator, which handled many more expressions
than the CheckForIntOverflow whitelist did.

llvm-svn: 301742
2017-04-29 09:33:46 +00:00
Nick Lewycky 19ae6dc853 ObjCBoxedExpr can't be evaluated by the constant expression evaluator.
A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects.

Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow.

llvm-svn: 301721
2017-04-29 00:07:27 +00:00
Nick Lewycky ad8886896e In the expression evaluator, visit the index of an ArraySubscriptExpr even if we can't evaluate the base, if the evaluation mode tells us to continue evaluation.
llvm-svn: 301522
2017-04-27 07:27:36 +00:00
Nick Lewycky 20edee6a3e In the expression evaluator, descend into both the true and false expressions of a ConditionalOperator when the condition can't be evaluated and we're in an evaluation mode that says we should continue evaluating.
llvm-svn: 301520
2017-04-27 07:11:09 +00:00
Benjamin Kramer f6021ecddc Apply clang-tidy's performance-unnecessary-value-param to parts of clang.
No functionality change intended.

llvm-svn: 298443
2017-03-21 21:35:04 +00:00
Roger Ferrer Ibanez 3fa38a14ac Honor __unaligned in codegen for declarations and expressions
This patch honors the unaligned type qualifier (currently available through he
keyword __unaligned and -fms-extensions) in CodeGen. In the current form the
patch affects declarations and expressions. It does not affect fields of
classes.

Differential Revision: https://reviews.llvm.org/D30166

llvm-svn: 297276
2017-03-08 14:00:44 +00:00
Eric Fiselier 20f25cb6df [coroutines] Add DependentCoawaitExpr and fix re-building CoroutineBodyStmt.
Summary:
The changes contained in this patch are:

1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to  `p.await_transform(<expr>)`  when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4.  Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.


@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.



Reviewers: rsmith, GorNishanov

Reviewed By: rsmith

Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits

Differential Revision: https://reviews.llvm.org/D26057

llvm-svn: 297093
2017-03-06 23:38:15 +00:00
Richard Smith 64cb9ca456 PR32034: Evaluate _Atomic(T) in-place when T is a class or array type.
This is necessary in order for the evaluation of an _Atomic initializer for
those types to have an associated object, which an initializer for class or
array type needs.

llvm-svn: 295886
2017-02-22 22:09:50 +00:00
Benjamin Kramer aad1bdc863 Silence sign compare warning. NFC.
ExprConstant.cpp:6344:20: warning: comparison of integers of different
signs: 'const size_t' (aka 'const unsigned long') and 'typename
iterator_traits<Expr *const *>::difference_type' (aka 'long')
[-Wsign-compare]

llvm-svn: 295320
2017-02-16 14:08:41 +00:00
Anastasia Stulova 58984e7087 [OpenCL] Correct ndrange_t implementation
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.

Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.

Review: D28058

Patch by Dmitry Borisenkov!  
 

llvm-svn: 295311
2017-02-16 12:27:47 +00:00
Faisal Vali 051e3a2b7d [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.
Enable evaluation of captures within constexpr lambdas by using a strategy similar to that used in CodeGen:
  - when starting evaluation of a lambda's call operator, create a map from VarDecl's to a closure's FieldDecls
  - every time a VarDecl (or '*this) that represents a capture is encountered while evaluating the expression via the expression evaluator (specifically the LValueEvaluator) in ExprConstant.cpp - it is replaced by the corresponding FieldDecl LValue (an Lvalue-to-Rvalue conversion on this LValue representation then determines the right rvalue when needed).

Thanks to Richard Smith and Hubert Tong for their review and feedback!

https://reviews.llvm.org/D29748

llvm-svn: 295279
2017-02-16 04:12:21 +00:00
George Burgess IV f9013bf8f0 Don't let EvaluationModes dictate whether an invalid base is OK
What we want to actually control this behavior is something more local
than an EvalutationMode. Please see the linked revision for more
discussion on why/etc.

This fixes PR31843.

Differential Revision: https://reviews.llvm.org/D29469

llvm-svn: 294800
2017-02-10 22:52:29 +00:00
George Burgess IV 5731707668 Fix typo. NFC
llvm-svn: 293871
2017-02-02 07:53:55 +00:00
Akira Hatanaka bc332648e8 Handle ObjCEncodeExpr in extractStringLiteralCharacter.
This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.

rdar://problem/30111207

llvm-svn: 293596
2017-01-31 02:31:39 +00:00
Richard Smith d6cc198d53 Improve fix for PR28739
Don't try to map an APSInt addend to an int64_t in pointer arithmetic before
bounds-checking it. This gives more consistent behavior (outside C++11, we
consistently use 2s complement semantics for both pointer and integer overflow
in constant expressions) and fixes some cases where in C++11 we would fail to
properly check for out-of-bounds pointer arithmetic (if the 2s complement
64-bit overflow landed us back in-bounds).

In passing, also fix some cases where we'd perform possibly-overflowing
arithmetic on CharUnits (which have a signed underlying type) during constant
expression evaluation.

llvm-svn: 293595
2017-01-31 02:23:02 +00:00
Richard Smith 642a2365fb PR28739: Check that integer values fit into 64 bits before extracting them as 64 bit values for pointer arithmetic.
This fixes various ways to tickle an assertion in constant expression
evaluation when using __int128. Longer term, we need to figure out what should
happen here: either any kind of overflow in offset calculation should result in
a non-constant value or we should truncate to 64 bits. In C++11 onwards, we're
effectively already checking for overflow because we strictly enforce array
bounds checks, but even there some forms of overflow can slip past undetected.

llvm-svn: 293568
2017-01-30 23:30:26 +00:00
Richard Smith 600b5261c4 PR0091R3: Implement parsing support for using templates as types.
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.

We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.

llvm-svn: 293207
2017-01-26 20:40:47 +00:00
Richard Smith 5e29dd3fe0 P0426: Make the library implementation of constexpr char_traits a little easier
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.

llvm-svn: 292555
2017-01-20 00:45:35 +00:00
David L. Jones f55ce36c02 Allow constexpr construction of subobjects unconditionally, not just in C++14.
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:

  struct foo_t { union { int i; volatile int j; } u; };

  __attribute__((__require_constant_initialization__))
  static const foo_t x = {{0}};

Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:

  union foo_u { int i; volatile int j; };
  __attribute__((__require_constant_initialization__))
  static const foo_u x = {0};

does have a constant initializer.

(This was triggered by musl's pthread_mutex_t type when building under C++11.)

Reviewers: rsmith

Subscribers: EricWF, cfe-commits

Differential Revision: https://reviews.llvm.org/D28427

llvm-svn: 291480
2017-01-09 21:38:07 +00:00
George Burgess IV 177399e227 Add the diagnose_if attribute to clang.
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:

```
constexpr int foo(int a)
  __attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
                                      "expensive.", "warning")));

int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```

It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:

```
constexpr int bar(int a) {
  foo(a);
  return 0;
}

constexpr int i = bar(10);
```

We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.

Release notes will appear shortly. :)

Differential Revision: https://reviews.llvm.org/D27424

llvm-svn: 291418
2017-01-09 04:12:14 +00:00
Faisal Vali c72a08c1f6 [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions.
Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.

This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);

Lambda captures are still not supported for constexpr lambdas.

llvm-svn: 291416
2017-01-09 03:02:53 +00:00
Faisal Vali d92e7499fb [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the expression-evaluator to evaluate the static-invoker.
This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year.  While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then.

I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization).

Thanks!

llvm-svn: 291397
2017-01-08 18:56:11 +00:00
George Burgess IV 7fb7e361bf Re-add objectsize function/incomplete type checks.
I accidentally omitted these when refactoring this code. This caused
problems when building parts of the test-suite on MacOS.

llvm-svn: 290916
2017-01-03 23:35:19 +00:00
George Burgess IV b531698ff0 Emit CCEDiags when evaluating a const variable.
This addresses post-review feedback from r290577.

llvm-svn: 290584
2016-12-27 05:33:20 +00:00
Egor Churaev 89831421af Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers: yaxunl, cfe-commits, bader

Differential Revision: https://reviews.llvm.org/D27981

llvm-svn: 290431
2016-12-23 14:55:49 +00:00
George Burgess IV e37633713d Add the alloc_size attribute to clang, attempt 2.
This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.

Fingers crossed that this patch sticks this time. :)

Original commit message:

This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
  number of bytes handed back to us by malloc/realloc/calloc/any user
  functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
  is OK sometimes. This is why we have a change in
  test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
  unrelated tests. Richard Smith okay'ed this idea some time ago in
  person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
  D26410. Lack of uniquing only really shows up as a problem when
  combined with our new eagerness in the face of const.

llvm-svn: 290297
2016-12-22 02:50:20 +00:00
Daniel Jasper 9068938eb0 Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.

Replied on the commit with more details.

llvm-svn: 290173
2016-12-20 10:05:04 +00:00
Egor Churaev 67c3f3ec68 [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.

Reviewers: Anastasia

Subscribers: cfe-commits, yaxunl, bader

Differential Revision: https://reviews.llvm.org/D27569

llvm-svn: 290171
2016-12-20 09:15:21 +00:00
Chandler Carruth d7738fe6ad Revert r290149: Add the alloc_size attribute to clang.
This commit fails MSan when running test/CodeGen/object-size.c in
a confusing way. After some discussion with George, it isn't really
clear what is going on here. We can make the MSan failure go away by
testing for the invalid bit, but *why* things are invalid isn't clear.
And yet, other code in the surrounding area is doing precisely this and
testing for invalid.

George is going to take a closer look at this to better understand the
nature of the failure and recommit it, for now backing it out to clean
up MSan builds.

llvm-svn: 290169
2016-12-20 08:28:19 +00:00
George Burgess IV a747027bc6 Add the alloc_size attribute to clang.
This patch does three things:

- Gives us the alloc_size attribute in clang, which lets us infer the
  number of bytes handed back to us by malloc/realloc/calloc/any user
  functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
  is OK sometimes. This is why we have a change in
  test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
  unrelated tests. Richard Smith okay'ed this idea some time ago in
  person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
  D26410. Lack of uniquing only really shows up as a problem when
  combined with our new eagerness in the face of const.

Differential Revision: https://reviews.llvm.org/D14274

llvm-svn: 290149
2016-12-20 01:05:42 +00:00
Yaxun Liu 402804b6d6 Re-commit r289252 and r289285, and fix PR31374
llvm-svn: 289787
2016-12-15 08:09:08 +00:00
Richard Smith dfe85e2d88 [c++1z] Permit constant evaluation of a call through a function pointer whose
type differs from the type of the actual function due to having a different
exception specification.

llvm-svn: 289754
2016-12-15 02:35:39 +00:00
Nico Weber 7849eeb035 Revert 289252 (and follow-up 289285), it caused PR31374
llvm-svn: 289713
2016-12-14 21:38:18 +00:00
Stephan Bergmann 17c7f70362 Replace APFloatBase static fltSemantics data members with getter functions
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.

Differential Revision: https://reviews.llvm.org/D26671

llvm-svn: 289647
2016-12-14 11:57:17 +00:00
Reid Kleckner 06df402b06 Align EvalInfo in ExprConstant to avoid PointerUnion assertions
32-bit MSVC doesn't provide more than 4 byte stack alignment by default.
This conflicts with PointerUnion's attempt to make assertions about
alignment. This fixes the problem by explicitly asking the compiler for
8 byte alignment.

llvm-svn: 289575
2016-12-13 19:48:32 +00:00
Richard Smith 410306bf6e Add two new AST nodes to represent initialization of an array in terms of
initialization of each array element:

 * ArrayInitLoopExpr is a prvalue of array type with two subexpressions:
   a common expression (an OpaqueValueExpr) that represents the up-front
   computation of the source of the initialization, and a subexpression
   representing a per-element initializer
 * ArrayInitIndexExpr is a prvalue of type size_t representing the current
   position in the loop

This will be used to replace the creation of explicit index variables in lambda
capture of arrays and copy/move construction of classes with array elements,
and also C++17 structured bindings of arrays by value (which inexplicably allow
copying an array by value, unlike all of C++'s other array declarations).

No uses of these nodes are introduced by this change, however.

llvm-svn: 289413
2016-12-12 02:53:20 +00:00
Yaxun Liu 8f66b4b44a Add support for non-zero null pointer for C and OpenCL
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.

Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.

Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.

Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.

This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.

This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.

Differential Revision: https://reviews.llvm.org/D26196

llvm-svn: 289252
2016-12-09 19:01:11 +00:00
Richard Smith b8c0f553ed DR1295 and cleanup for P0135R1: Make our initialization code more directly
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.

In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.

llvm-svn: 289250
2016-12-09 18:49:13 +00:00
Richard Smith 122f88d481 [c++17] P0135R1: Guaranteed copy elision.
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.

llvm-svn: 288866
2016-12-06 23:52:28 +00:00
Richard Smith b3189a1802 DR1213: element access on an array xvalue or prvalue produces an xvalue. In the
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.

This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.

llvm-svn: 288654
2016-12-05 07:49:14 +00:00
Richard Smith 8110c9df22 Support constant expression evaluation for wchar_t versions of simple string
functions, in order to support constexpr std::char_traits<wchar_t>.

llvm-svn: 288193
2016-11-29 19:45:17 +00:00
Richard Smith 6328cbd31b Outline evaluation of calls to builtins to avoid inflating stack usage for the
common case of a call to a non-builtin, particularly for unoptimized ASan
builds (where the per-variable stack usage can be quite high).

llvm-svn: 287066
2016-11-16 00:57:23 +00:00
Faisal Vali 0528a31ddf Fix PR28366: Handle variables from enclosing local scopes more gracefully during constant expression evaluation.
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.


void f(char c) { 
  struct X {
    static constexpr char f() { 
      return c; // error gracefully here as opposed to crashing.
    }
  };
  int I = X::f();
}

llvm-svn: 286748
2016-11-13 06:09:16 +00:00
Richard Smith e950795a03 [c++1z] Support constant folding for __builtin_strchr and __builtin_memchr.
llvm-svn: 286699
2016-11-12 01:39:56 +00:00
Richard Smith e151bab2fc [c++1z] Add constant-folding support for strcmp, strncmp, and memcmp, to
support constexpr char_traits.

llvm-svn: 286678
2016-11-11 23:43:35 +00:00
Benjamin Kramer 33e9760376 Remove move constructors that are identical to the generated default move ctor.
llvm-svn: 284856
2016-10-21 18:55:07 +00:00
Justin Bogner fe183d7e96 AST: Prefer LLVM_NODISCARD to LLVM_ATTRIBUTE_UNUSED_RESULT
llvm-svn: 284366
2016-10-17 06:46:35 +00:00
Yaron Keren e0bcdd4d25 Un-tabify source files, NFC.
llvm-svn: 283657
2016-10-08 06:45:10 +00:00
Samuel Antao 1197a1612d Reorder initializers in CallStackFrame so that we don't get a warning.
llvm-svn: 281923
2016-09-19 18:13:13 +00:00
Alexander Shaposhnikov fbcf29bc5a Remove excessive padding from the struct CallStackFrame
The struct CallStackFrame is in lib/AST/ExprConstant.cpp
inside anonymous namespace.
This diff reorders the fields and removes excessive padding.
Test plan: make -j8 check-clang

Differential revision: https://reviews.llvm.org/D23901

llvm-svn: 281907
2016-09-19 15:57:29 +00:00
George Burgess IV f8f6324983 [Sema] Fix PR30346: relax __builtin_object_size checks.
This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:

```
struct sockaddr {
  /* snip */
  char sa_data[14];
};

void foo(const char *s) {
  size_t slen = strlen(s) + 1;
  size_t added_len = slen <= 14 ? 0 : slen - 14;
  struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
  strcpy(sa->sa_data, s);
  // ...
}
```

`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.

Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).

In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.

I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.

llvm-svn: 281277
2016-09-12 23:50:35 +00:00
Richard Smith 97fcf4be9b Explicitly generate a reference variable to hold the initializer for a
tuple-like decomposition declaration. This significantly simplifies the
semantics of BindingDecls for AST consumers (they can now always be evalated
at the point of use).

llvm-svn: 278640
2016-08-14 23:15:52 +00:00
Richard Smith dca60b4958 P0217R3: Constant expression evaluation for decomposition declarations.
llvm-svn: 278447
2016-08-12 00:39:32 +00:00
Yaxun Liu 0bc4b2d337 [OpenCL] Generate opaque type for sampler_t and function call for the initializer
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.

This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.

Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.

This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).

Differential Revision: https://reviews.llvm.org/D21567

llvm-svn: 277024
2016-07-28 19:26:30 +00:00
Richard Smith cb2ba5a5a7 Fix some minor issues found by Coverity.
llvm-svn: 275925
2016-07-18 22:37:35 +00:00