[cfe-commits] r53221 - /cfe/trunk/lib/AST/ExprConstant.cpp
Eli Friedman
eli.friedman at gmail.com
Mon Jul 7 23:52:52 PDT 2008
On Mon, Jul 7, 2008 at 10:49 PM, Anders Carlsson <andersca at mac.com> wrote:
> + APValue VisitBinaryOperator(const BinaryOperator *E) {
> + // The LHS of a constant expr is always evaluated and needed.
> + llvm::APSInt Result(32);
> + if (!Evaluate(E->getRHS(), Result, Ctx))
> + return APValue();
> +
> + llvm::APSInt RHS(32);
> + if (!Evaluate(E->getRHS(), RHS, Ctx))
> + return APValue();
Typo with getRHS twice? Also, we don't need/want to evaluate the RHS
for && and ||.
> + case BinaryOperator::Shl:
> + Result <<=
> + static_cast<uint32_t>(RHS.getLimitedValue(Result.getBitWidth()-1));
> + break;
> + case BinaryOperator::Shr:
> + Result >>=
> + static_cast<uint32_t>(RHS.getLimitedValue(Result.getBitWidth()-1));
> + break;
Maybe we should fail if the RHS is larger than the bitwidth of the
Result? It's undefined behavior, so attempting to give a result seems
confusing.
> + case BinaryOperator::Comma:
> + // C99 6.6p3: "shall not contain assignment, ..., or comma operators,
> + // *except* when they are contained within a subexpression that is not
> + // evaluated". Note that Assignment can never happen due to constraints
> + // on the LHS subexpr, so we don't need to check it here.
> + // FIXME: Need to come up with an efficient way to deal with the C99
> + // rules on evaluation while still evaluating this. Maybe a
> + // "evaluated comma" out parameter?
> + return APValue();
> + }
Mmmm... actually, thinking it over a bit more, we don't actually need
to do anything here unless we care about evaluating comma operators.
I can't imagine any situation where that would be useful, since C
constant expressions aren't allowed to contain evaluated commas, and
nobody would write real code with a comma with both sides constant.
> + // sizeof(vla) is not a constantexpr: C99 6.5.3.4p2.
> + if (!E->getSubExpr()->getType()->isConstantSizeType()) {
> + // FIXME: Should we attempt to evaluate this?
We definitely should evaluate the alignof case. For the sizeof case,
I think it's also reasonable to try and evaluate it. (Although doing
that does run into an O(n^2) issue with many-dimensional VLAs... not
sure what to do about that. I'm almost tempted to cache constant
expression evaluation results, but it would be a lot of memory bloat.)
-Eli
More information about the cfe-commits
mailing list