[PATCH, rtl-optimization]: Fix PR37997: ICE shifting byte to the right with constant > 7FFFFFFF

[Richard Guenther]

On Wed, Sep 9, 2009 at 4:33 PM, Eric Botcazou<ebotcazou@adacore.com> wrote:
>> I fail to see any problem.  build_binary_op earlier converted all shift
>> counts to type int, but there is no problem with that since it will only
>> change the value in cases of undefined behavior and you need to handle
>> shifts by INT_MIN anyway.
>
> I have no problem with that.
>
>> There is no indication I can see in anything you have posted in this
>> dicussion that the front end is generating any invalid trees or GIMPLE; it's
>> for the expanders to handle arbitrary constant or nonconstant shift counts
>> whose type may be unrelated to the type of the expression being shifted
>> (where if it is known that the count  is negative or >= width of type, the
>> result is arbitrary).
>
> I think it's a pure matter of convention, but I see no reason to make a
> questionable change in the middle-end because of a hole in the handling of
> non-sensical code in a front-end.
>
>             /* We can shorten only if the shift count is less than the
>                number of bits in the smaller type size.  */
>             && compare_tree_int (op1, TYPE_PRECISION (TREE_TYPE (arg0))) < 0
>
> obviously overlooks the negative case.

IMHO the frontend optimization is premature.  It's the middle-ends
job to do this kind of optimization.

Richard.