On 01/22/2016 12:20 PM, Marek Polacek wrote:
On Thu, Jan 21, 2016 at 01:49:14PM -0500, Jason Merrill wrote:
On 01/21/2016 01:25 PM, Marek Polacek wrote:
The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.
Why didn't we fold away the NOP_EXPR before calling fold_convert? I guess
we shouldn't call fold_convert on an un-folded operand.
So we start with fargs[j] = maybe_constant_value (argarray[j]); in
build_over_call, where argarray[j] is
(const struct
{
void Dict::<T462> (struct Dict *, int) * __pfn;
long int __delta;
} &) &TARGET_EXPR <D.2347, (struct d) <<< Unknown tree: ptrmem_cst >>>>
Later on, we end up in cxx_eval_constant_expression with
t == (struct d) <<< Unknown tree: ptrmem_cst >>>
so we go to the
3607 case NOP_EXPR:
case. Here cxx_eval_constant_expression evaluates the inner ptrmem_cst,
then there's
3619 if (TREE_CODE (op) == PTRMEM_CST
3620 && !TYPE_PTRMEM_P (type))
3621 op = cplus_expand_constant (op);
but that doesn't trigger, because type is TYPE_PTRMEM_P.
Then we fold () the whole expression but that doesn't change the expression
(and I don't think it should do anything with C++-specific PTRMEM_CST) so we're
stuck with NOP_EXPR around PTRMEM_CST.
So maybe cxx_eval_constant_expression should handle PTRMEM_CSTs wrapped in
NOP_EXPR specially, but I don't know how.
If we have a NOP_EXPR to the same type, we should strip it here.
Jason