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: [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
--


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