RFC: PR 19650

[Roger Sayle]

On Thu, 27 Jan 2005, Dale Johannesen wrote:
> I'm not sure where in the twisty little passages this should be fixed,
> but fold_binary_op_with_conditional_arg is taking a type from the
> EQ_EXPR, even though that should always be boolean (right)?  Which is
> suspicious, and I'm inclined to think it should be using the input type
> instead.
>
> Does this look like the right approach?

Ahh, the perils of STRIP_NOPS.  Firstly, the type that corresponds to
the result of EQ_EXPR is defined by the front-end, "bool" in C++, "int"
in C, and even several different LOGICAL(n) types in the gfortran
front-ends, so "fold" should always be using the type of the EQ_EXPR.

However, the problem is that we've lost the NOP_EXPR cast from bool
to "unsigned long" thanks to STRIP_NOPS.  This stripping may also have
affected COND_EXPRs in addition to relational operations, so I think
the appropriate fix is actually something like:


    if (lhs == 0)
+     {
+	true_value = fold_convert (type, true_value);
!       lhs = fold (cond_first_p ? build2 (code, type, true_value, arg)
!                                 : build2 (code, type, arg, true_value));
+     }
    if (rhs == 0)
+     {
+       false_value = fold_convert (type, false_value);
!       rhs = fold (cond_first_p ? build2 (code, type, false_value, arg)
!                                : build2 (code, type, arg, false_value));
+     }


This should avoid potential problems with true_value or false_value
being "void" in a COND_EXPR, and matches the intended semantics.

Could you see if this untested suggestion works for you?

Roger
--