[PATCH]es to fix PR24439 (ICE in invert_truthvalue called from C++ frontend)

Richard Guenther rguenther@suse.de
Thu Oct 20 13:40:00 GMT 2005


On Thu, 20 Oct 2005, Roger Sayle wrote:

> 
> 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).

Ok, I will do this.  Though we need to check operand2 also.

Richard.



More information about the Gcc-patches mailing list