C++ PATCH for constexpr

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| On 11/29/2009 02:08 PM, Gabriel Dos Reis wrote:
| > Jason Merrill<jason@redhat.com>  writes:
| 
| > | What link-time or load-time constants do you mean to exclude?
| >
| > What I meant was that there are expressions that may be found link-time or
| > load-time constants by that we cannot legitimately consider compile time
| > constant from the languge point of view.  For example, I had in mind
| > this scenario
| >
| >       constexpr int n = 8;
| >       int m = n * 8;
| >       int main() {
| >          return m;
| >       }
| >
| > 'm' may be considered a load-time constant, but we should not accept it.
| 
| m isn't any sort of constant, it's just a statically initialized
| variable.  Anything else?

It surely isn't constant in the C++ front-end sense.  The issue is
whether a link-time optimization would decide it is constant -- which it
is.  I was just making that distinction.  I don't feel wedded to it.

| > | Or, better, can we just make VALID_FOR_STATIC_INITIALIZATION_P a
| > | function that knows to descend into CONSTRUCTORs so we don't need a
| > | flag at all?  It seems like potential_constant_expression might
| > | already be that function if you add a flag to control the special parm
| > | handling.
| >
| > I chose a flag based on the perspective that people would start using
| > more and more constants of class types (and combinations with other
| > symbolic references), and for efficiency reason we
| > should just "remember" that a particular expression tree we already
| > processed denotes a compile time constant.
| 
| I'm dubious that this checking would even show up in a callgraph
| profile; I don't expect a literal class to have many members, so
| walking through the elements of a constructor shouldn't take
| significant time.

A literal class can have base many classes, and arbitrary inheritance
depth. So, even though I would expect a literal class to have on average
2-3 members, the nesting structure can be non-trivial.

| 
| But feel free to use a TREE_LANG_FLAG for CONSTRUCTORs; I only object
| to claiming a flag for all expressions.

there are three classes of expressions that currently use the flag:
symbolic address references, symbolic pointers, and CONSTRUCTORs.
Are you suggesting each of those three should each a separate flag,
instead of using one from the spare bit?


| 
| > The other reason was that, I thought it is a good thing to build in a
| > non-circular sanity check during compile time evaluation:  Basically,
| > during type checking we decide that a particular expression denotes a
| > compile time constant in a given context.  Then we go off evaluating it.
| > If during evaluation we fail to reduce a expression to a constant
| > and we call again the same routine that told us that that expression is
| > a constant, it would not be obvious where a potential bug was.
| 
| How would that be different from the function setting a flag?  We're
| getting the same value either way.

yes, but not by the same process.
there are two separate things involved in the approach: 
  (1) semantics checking that an expression is compile time constant
  (2) evaluation of an expression that passes (1).

The C++ front-end has control over (1), but has much less control over (2)

What else need change?
(I'm about to head for a hectic travel in about 48 hours, so anything
that can be done by then is good, otherwise, it would be after the 20th.)

-- Gaby