Re: fold bug with multiply and cast and conditional

[Roger Sayle <roger at eyesopen dot com>]

Hi Andrew,

On Wed, 8 Dec 2004, Andrew Pinski wrote:
> Also looking at the code it looks like we never set the variables lhs
> and rhs for the non COND_EXPR case.  Also I think this is a regression
> from 3.4.x where we do the correct thing for this case.
> I think this was changed with the following patch:
> 2004-05-20  Roger Sayle  <roger@eyesopen.com>
>
>       PR middle-end/3074
>       * fold-const.c (strip_compound_expr): Delete function.
>       (fold_binary_op_with_conditional_arg): Only perform transformations
>       "a + (b?c:d) -> b ? a+c : a+d" and "(b?c:d) + a -> b ? c+a : d+a"
>       when a is constant.  This greatly simplifies this routine.

I think you're misattributing your the problem to the function
fold_binary_op_with_conditional_arg, though clearly you haven't
given enough information to determine where things are actually
going  wrong.

In fold_binary_op_with_conditional_arg, the variables "lhs" and "rhs"
are initially set to NULL_TREE at the top of the function.  The lhs
and rhs are only assigned values in the COND_EXPR case, for exceptional
circumstances where "lhs" and/or "rhs" are assigned a tree of void
type to override the usual case processing below.

The normal case processing then happens after the COND_EXPR/boolean
cases where we check whether "lhs" and "rhs" are still NULL (i.e. they
don't throw an exception or fail to return), in which case we construct
them as we should.

Hopefully, the above explanation should be clear enough, and show
that the current implementation of fold_binary_op_with_condition_arg
is correct.  Fortunately, my patch you quote above, made this function
much earier to read than it was previously.  But even as written it
should be clear that lhs and rhs are never used without previously
being assigned an appropriate value.


Best of luck debugging your problem, wherever it may be :>  My initial
guess would be that your combiner is not correctly casting the types of
the operands of the multiplication to the appropriate/result type.
Just a guess, but this would explain why you can't reproduce it with
any of GCC's language front-ends, which correctly preserve tree type
safety.

Roger
--