C++ PATCH for constexpr
Gabriel Dos Reis
gdr@cs.tamu.edu
Tue Dec 1 00:24:00 GMT 2009
Jason Merrill <jason@redhat.com> writes:
| On 11/30/2009 03:03 AM, Gabriel Dos Reis wrote:
| > 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.
|
| 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.
OK.
|
| > | 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
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Department of Computer Science & Engineering; TAMU
301, Bright Building -- College Station, TX 77843-3112
More information about the Gcc-patches
mailing list