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