This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rtl-optimization]: Fix PR37997: ICE shifting byte to the right with constant > 7FFFFFFF
On Wed, 9 Sep 2009, Eric Botcazou 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.
--
Joseph S. Myers
joseph@codesourcery.com