gcc-patches@gcc.gnu.org
[Top] [All Lists]

Re: C++ PATCH for constexpr

Subject: Re: C++ PATCH for constexpr
From: Gabriel Dos Reis
Date: Mon, 30 Nov 2009 18:25:17 -0600
Jason Merrill <jason@xxxxxxxxxx> writes:

| 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.

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@xxxxxxxxxxx), Assistant Professor
              http://www.cs.tamu.edu/people/faculty/gdr
          Department of Computer Science & Engineering; TAMU
        301, Bright Building -- College Station, TX 77843-3112

<Prev in Thread] Current Thread [Next in Thread>