This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH for constexpr
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Jason Merrill <jason at redhat dot com>
- Cc: bkoz at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Sun, 29 Nov 2009 11:26:44 -0600
- Subject: Re: C++ PATCH for constexpr
- References: <87bpiosq4g.fsf@gauss.cs.tamu.edu> <4B12979A.5070409@redhat.com>
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