[cfe-dev] integer constant expression oh my!

[Daniel Dunbar]

Excellent Chris, the direction looks good to me.

On Sun, Nov 16, 2008 at 3:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Sun, Nov 16, 2008 at 1:51 PM, Chris Lattner <clattner at apple.com> wrote:
>> I wrote up some thoughts about how I think that constants should
>> eventually be handled in clang:
>> http://clang.llvm.org/docs/InternalsManual.html#Constants
>>
>> The goal is for Expr::isConstantExpr and many other things to
>> eventually go away, and only have one piece of code that does the
>> constant folding tree walk.  Before we get too far along this path, I
>> thought it would be good to see if this makes sense to others... so,
>> what say you all? :)
>
> I think it's generally a good direction; it's certainly a lot less
> confusing than having multiple routines doing very similar things.
>
> My only real concern about the approach is that putting ICE checking
> into Expr::Evaluate might not be a good idea.  isICE has to enforce
> restrictions that seem unintuitive to enforce in Evaluate, like
> restrictions on unevaluated sub-expressions.  I think it would be
> better to rewrite ICE checking around Evaluate, but keep the
> ICE-specific logic separate.

Hmmm, this is true, but currently having two implementations that do
very similar traversals is a bit confusing and has been error prone
(i.e., bugs in one and not the other, patches that only fix one and
not the other).

I'm not sure what you mean about rewrite ICE checking around Evaluate.
Is this just about replacing pieces like sizeof with calls to
Evaluate?

> Also, something you didn't mention: do we want to return information
> about integer/pointer overflow (PR2729)?  I'm guessing that we do,
> although it'll be a bit of a pain to implement.

Seems like we should.

> "__builtin_choose_expr: The condition is required to be an integer
> constant expression..."  Our implementation currently has this
> requirement, but where in the gcc docs does it imply that it needs to
> be an ICE?  Not that I really trust the gcc docs at all... "This
> built-in function returns exp1 if [...] Otherwise it returns 0."

It is explicit:
"You can use the built-in function __builtin_choose_expr ... if
const_exp, which is a constant expression that must be able to be
determined at compile time, ..."

 - Daniel