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


Jason Merrill <jason@redhat.com> 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


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