RFH and fix for PR32367

[Richard Guenther]

On 6/19/07, Sebastian Pop <sebpop@gmail.com> wrote:
> Hi,
>
> 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.  The number of cases that contained this pattern is small
> enough, and it does not occur during the bootstrap of gcc, only the
> following testcases triggered that pattern:
> gcc.c-torture/compile/pr14692.c
> gcc.dg/tree-ssa/predcom-5.c
> gcc.dg/tree-ssa/tailrecursion-5.c
> gfortran.dg/array_constructor_7.f90
> gfortran.dg/stfunc_4.f90
>
> The attached patch passed bootstrap and testing on i686-linux.
> Committed to trunk.
>
> 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.

I believe it currenlty does the reverse transform.

Richard.

> Thanks,
> Sebastian
>
>         PR tree-optimization/32367
>         * tree-chrec.h (build_polynomial_chrec): Verify that the left hand side
>         of the chrec has no evolution in that loop.
>         * testsuite/gcc.dg/tree-ssa/pr32367.c: New.
>
>