RFC: PR 19650

[Dale Johannesen]

On Jan 27, 2005, at 2:19 PM, Roger Sayle wrote:
>     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));
> +     }
>
> Could you see if this untested suggestion works for you?

Unfortunately, this breaks bootstrap on ppc due to miscompiling some of 
the PPC-specific
code, which boils down to this loop:

       unsigned int i;
       for (i = 0;
                ((i) < 4 ? (i) + 3 : (~(unsigned int) 0)) != (~(unsigned 
int) 0);
                 ++i)
          continue;

Yes, that is a stupid way to write i=4, but there it is (well hidden by 
macros of course).
fold is presented with the following:

  <ne_expr 0x4267e4e0
     type <integer_type 0x4260b680 int public SI
     arg 0 <cond_expr 0x4267e4b0
         type <integer_type 0x4260b700 unsigned int public unsigned SI
         arg 0 <le_expr 0x4267e450 type <integer_type 0x4260b680 int>
             arg 0 <var_decl 0x42680880 i>
             arg 1 <integer_cst 0x42684000 constant invariant 3>>
         arg 1 <plus_expr 0x4267e480 type <integer_type 0x4260b700 
unsigned int>
             arg 0 <var_decl 0x42680880 i>
             arg 1 <integer_cst 0x42684000 3>>
         arg 2 <integer_cst 0x42606640 constant invariant 4294967295>>
     arg 1 <integer_cst 0x42606640 4294967295>>

and the transformation above changes  4294967295 to -1,  which compares 
as != 429467295.
Now what?  Perhaps the transformation should not be applied in the 
COND_EXPR case?