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

Re: C++ PATCH for constexpr

Subject: Re: C++ PATCH for constexpr
From: Gabriel Dos Reis
Date: Sun, 29 Nov 2009 11:26:44 -0600
Jason Merrill <jason@xxxxxxxxxx> writes:

| On 11/26/2009 08:39 PM, Gabriel Dos Reis wrote:
| > +      if (!same_type_p (TREE_TYPE (lhs_arg), TREE_TYPE (rhs_arg)))
| > +        return 0;
| 
| You were going to turn this into an assert?

Oops :-(

| 
| > +      /* For member function, the first argument is a pointer to the 
implied
| > +         object.  And for an object contruction, don't bind `this' before
| > +         it is fully constructed.  */
| > +      if (i == 0 && TREE_CODE (t) == AGGR_INIT_EXPR)
| > +        continue;
| 
| Here you're still assuming that all AGGR_INIT_EXPR are constructor
| calls.  Again, check DECL_CONSTRUCTOR_P (fun) instead.

Thanks, fixed.

| > +constexpr_call_equal(const void *p, const void *q)
| > +    cxx_eval_constant_expression(&new_call, new_call.fundef->body);
| > +  return VEC_index(constructor_elt, CONSTRUCTOR_ELTS (ary),
| 
| Missing space before (.

Fixed.

| > +    case CONVERT_EXPR:
| > +    case VIEW_CONVERT_EXPR:
| > +      /* -- an array-to-pointer conversion that is applied to an lvalue
| > +            that designates an object with thread or automatic storage
| > +            duration;
| > +         -- a type conversion from a pointer or pointer-to-member type
| > +            to a literal type.  */
| > +      {
| > +        tree from = TREE_OPERAND (t, 0);
| > +        tree source = TREE_TYPE (from);
| > +        tree target = TREE_TYPE (t);
| > +        if (TYPE_ARRAY_P (source) && TYPE_PTR_P (target)
| > +            && has_automatic_or_tls (from))
| 
| The array-to-pointer conversion is expressed with ADDR_EXPR; see
| decay_conversion.

OK, in that case the conversion will be handled by the ADDR_EXPR case which
subsumes this specific test then.

This goes back a question I had some time ago.  It is not clear to me
exactly which language constructs are mapped to these conversion nodes
(including NOP_EXPR).  I looked at the doc several times, but it does
not appear to me that there is a systematic semantics mapping in this
conversion part of the compiler.
Did I overlook something?

I'm regtesting a revised patch that includes your previous comments.

-- Gaby

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