This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH for constexpr


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?


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


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

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.


Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]