|
|
On 11/30/2009 03:03 AM, Gabriel Dos Reis wrote:
Jason Merrill<jason@xxxxxxxxxx> writes:
| On 11/29/2009 02:08 PM, Gabriel Dos Reis wrote:
|> Jason Merrill<jason@xxxxxxxxxx> 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.
But that distinction doesn't seem related to compile-time vs link-time;
it's a distinction between language-level constants and
optimization-level constants. The same thing would apply if 'm' were a
local variable in main(); it always has the value 16, but it isn't
usable in a constant expression.
| 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?
I was thinking that you would walk the tree to check the others.
> +lookup_parameter_binding (const constexpr_call *call, tree t)
> +{
> + tree b = purpose_member (t, call->bindings);
> + gcc_assert(b != NULL);
> + return b;
> +}
Don't you still need TREE_VALUE? Also, space before the ( in the assert
line.
Jason
|
|