This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFH and fix for PR32367
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 19 Jun 2007 23:57:57 +0200
- Subject: Re: RFH and fix for PR32367
- References: <cb9d34b20706191136l5caf53c8r18d367bac30b853d@mail.gmail.com>
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