This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH for c++/69379 (ICE with PTRMEM_CST wrapped in NOP_EXPR)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 22 Jan 2016 18:20:11 +0100
- Subject: Re: C++ PATCH for c++/69379 (ICE with PTRMEM_CST wrapped in NOP_EXPR)
- Authentication-results: sourceware.org; auth=none
- References: <20160121182532 dot GF25528 at redhat dot com> <56A1282A dot 8020904 at redhat dot com>
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.
Marek