Commit Graph

17 Commits

Author SHA1 Message Date
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
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
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
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
Nick Lewycky 49675ac409 Fix test that was incorrected merged between patches.
llvm-svn: 301787
2017-05-01 02:20:06 +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 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
Richard Trieu 729c8e9793 Adjust tests to have consistent integer sizes.
Add a triple to the run lines so that integers will the same sizes across runs.
Also add a compile time check to ensure the assumptions about sizes are met.

llvm-svn: 265991
2016-04-11 20:37:04 +00:00
Akira Hatanaka dfe2156f1b [Sema] Issue a warning for integer overflow in nested struct initializer
r257357 fixed clang to warn on integer overflow in struct initializers.
However, it didn't warn when a struct had a nested initializer. This
commit makes changes in Sema::CheckForIntOverflow to handle nested
initializers.

For example:

struct s {
  struct t {
    unsigned x;
  } t;
} s = {
  {
    .x = 4 * 1024 * 1024 * 1024
  }
};

rdar://problem/23526454

llvm-svn: 260360
2016-02-10 06:06:06 +00:00
Akira Hatanaka f5c136186f [Sema] Issue a warning for integer overflow in struct initializer
Clang wasn't issuing a warning when compiling the following code:

struct s {
  unsigned x;
} s = {
  .x = 4 * 1024 * 1024 * 1024
};

rdar://problem/23399683

Differential Revision: http://reviews.llvm.org/D15097

llvm-svn: 257357
2016-01-11 17:22:01 +00:00
Richard Smith ce8eca578d Explicitly permit undefined behavior in constant initializers for global
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.

llvm-svn: 254992
2015-12-08 03:21:47 +00:00
Richard Smith 0c6124ba82 PR17381: Treat undefined behavior during expression evaluation as an unmodeled
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.

This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.

This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:

  float f = 1e100;

are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.

llvm-svn: 254574
2015-12-03 01:36:22 +00:00
Josh Magee 4d1a79b8c0 Catch more cases when diagnosing integer-constant-expression overflows.
When visiting AssignmentOps, keep evaluating after a failure (when possible) in
order to identify overflow in subexpressions.

Differential Revision: http://reviews.llvm.org/D1238

llvm-svn: 228202
2015-02-04 21:50:20 +00:00