This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]