RFH and fix for PR32367

[Zdenek Dvorak]

Hello,

> Here is a first fix for this bug.  The patch ensures that the initial
> value is not varying in the loop in which we build the polynomial
> evolution.

IIRC, we intentionally allow the components of chrecs to be varying in
the loop -- instantiate_parameters/resolve_mixers are responsible for
eliminating such chrecs.  It might be better to find why this does
not happen (i.e., why instantiate_parameters/resolve_mixers are not
called or do not eliminate these chrecs) and fix the problem there.

> A further fix would improve fold to distribute the multiplication in
> the case of an (unsigned int) MULT_EXPR with a PLUS_EXPR already
> casted to (unsigned int), i.e.
> 
> #0  fold_build2_stat (code=MULT_EXPR, type=0xb7c41000, op0=0xb7cda6a0,
> op1=0xb7c32444) at ../../gcc/fold-const.c:12944
> (gdb)  call debug_generic_expr (type)
> unsigned int
> (gdb)  call debug_generic_expr (op0)
> (unsigned int) (n_20 + 65535)
> (gdb)  call debug_generic_expr (op1)
> 4
> (gdb)  call debug_generic_expr (tem)
> (unsigned int) (n_20 + 65535) * 4
> 
> I would expect to see the result in "tem" to be:
> (unsigned int) (n_20 * 4 + 262140)
> 
> As I'm not familiar with fold, I'd appreciate your help and suggestions
> on how to implement this transform.

In general, this cannot be done unless you know that the multiplication
does not overflow (assuming that the inner type is signed).

Zdenek