This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]es to fix PR24439 (ICE in invert_truthvalue called fromC++ frontend)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Oct 2005 07:36:02 -0600 (MDT)
- Subject: Re: [PATCH]es to fix PR24439 (ICE in invert_truthvalue called fromC++ frontend)
Hi Richard,
On Thu, 20 Oct 2005, Richard Guenther wrote:
> Here are two approaches to fix PR24439, one to make invert_truthvalue
> aware of the C++ frontend creating a COND_EXPR with mismatching types,
> one to fix the C++ frondend to not do so.
I believe that it was Edward De Bono who wrote something like when given
the choice between two options, always consider the third. :)
I think the real problem is in the middle-end's COND_EXPR case in
invert_truthvalue. This is currently written as:
case COND_EXPR:
return build3 (COND_EXPR, type, TREE_OPERAND (arg, 0),
invert_truthvalue (TREE_OPERAND (arg, 1)),
invert_truthvalue (TREE_OPERAND (arg, 2)));
instead it needs something like:
case COND_EXPR:
{
tree arg1 = TREE_OPERAND (arg1, 1);
return build3 (COND_EXPR, type, TREE_OPERAND (arg, 0),
VOID_TYPE_P (TREE_TYPE (arg1))
? arg1 : invert_truthvalue (arg1),
invert_truthvalue (TREE_OPERAND (arg, 2)));
}
This allows the middle-end to handle the known special case of
the first operand of a COND_EXPR throwing, and avoids the potential
room for mistakes if invert_truthexpr starts accepting arbitrary
void expressions.
Could you bootstrap and regression test a patch similar to the
one above? If it resolves the ICE in PR24439, it's OK for mainline
and the affected branches (unless Mark and/or Gaby have objections).
Thanks for investigating this,
Roger
--