[PATCH] Fix PR tree-optimization/19903

[Zdenek Dvorak]

Hello,

> > which is correct.  CHREC_LEFT and CHREC_RIGHT should have the same type,
> > namely the type of the chrec.  ~0u is correct representation for -1 in
> > unsigned type, and if there is some code that fails to notice that, it
> > is that code, not this place that ensures type sanity of the
> > expressions.
> 
> That seems questionable, given that neither -1 nor 0xffffffff fits in the type 
> natural___XDLU_0__2147483647, which has range 0..0x7fffffff.  So the new 
> constant doesn't even verify int_fits_type_p after conversion!

umm... now this is more problematic; sorry, I was not aware of the
restriction of the type.

The conservative solution is to return fold_convert (natural, chrec)
in this case.  Optimizers still are not able to handle this, but at
least the information is not lost and the optimizers could be updated.

What is TYPE_PRECISION of natural___XDLU_0__2147483647? If it would be
set to 31, things should work correctly, so I assume it is something
different?

Zdenek