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

[Uros Bizjak <ubizjak at gmail dot com>]

On 09/09/2009 05:31 PM, Joseph S. Myers wrote:
> > > 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.
> >      
> But what is done here is arbitrary; it's not the job of the front end to
> produce one form of valid GIMPLE rather than another for code that
> exhibits undefined behavior at runtime.  It's the job of the RTL expanders
> to take shifts with shift counts of any type or mode and ensure that they
> generate RTL that is valid for the particular machine; even if front ends
> avoid some cases of out-of-range constant shift counts, they cannot avoid
> the GIMPLE optimizers propagating out-of-range constants into the shift
> count later.
>    

I also share this opinion. The code from optabs.c is checking operands 
of an insn in order to fix the operand to satisfy insn constraints. 
However, supporting code fails to fix CONST_INTs, and although the 
testcase is undefined, it IMO shows the problem in the RTL part, not in 
the frontend part.

Uros.