This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR tree-optimization/19903
Hello,
> > it is clear how they should behave. The restriction relevant to the
> > problem iss that we want checs to satisfy
> >
> > TREE_TYPE (chrec) == TREE_TYPE (CHREC_LEFT (chrec)) == TREE_TYPE (CHREC_RIGHT (chrec)).
> >
> > I would strongly oppose changing this;
>
> Okay, I won't oppose. However, the above rule should be in the
> comments of chrec_convert together with an example illustrating why
> this should be satisfied.
>
> An example that comes to mind is:
>
> {(uint) 0, +, (uchar) 10} +
> {(uint) 0, +, (uchar) 250}
>
> that would produce a wrong result if CHREC_RIGHT is not (uint):
>
> {(uint) 0, +, (uchar) 4}
>
> Note that this could be dealt with in the chrec_plus function, such
> that it applies the conversion on the CHREC_RIGHT part.
if you want, add such a comment. To me, just the idea that CHREC_LEFT
could have type of different size than CHREC_RIGHT is plain insane,
so I never bothered to write it anywhere, but it is probably better to
state even such obvious assumptions.
> > Other possibility is to give up for types such that range of the
> > type is different from 1 << TYPE_PRECISION (type).
>
> It seems to me that failing in chrec_convert and returning a
> chrec_dont_know is the best solution.
This would be fine with me. Or returning fold_convert (new_type,
chrec).
Zdenek