[patch, scev] Fix PR tree-optimization/36630

[Daniel Berlin]

In that case, for Ira's original patch, do we need to STRIP_NOPS and
then put them back (depending on where the cast is) when we extract
the evolution for a given loop?
IE won't simply using STRIP_NOPS give wrong answers by eliminating the casts?

On Mon, Jul 28, 2008 at 8:21 AM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> Hi,
>
>> > On Thu, Jul 17, 2008 at 4:25 AM, Ira Rosen <IRAR@il.ibm.com> wrote:
>> > >
>> > > Hi,
>> > >
>> > > The test in PR36630 ICEs, since evolution_part_in_loop_num returns NULL
>> for
>> > > the access function (short int) {(short unsigned int) i_44, +, 1}_1).
>> > > Adding STRIP_NOPS before chrec's analysis solves the problem.
>> >
>> > How did the access function get a cast in front of it in the first place?
>> >
>> > My admittedly possibly out of date recollection is that casts can only
>> > occur inside the chrec.
>
> no, chrecs may appear anywhere in the expression; in this particular
> case, (short int) {(short unsigned int) i_44, +, 1}_1 cannot be folded
> to {(short int) i_44, +, 1}_1, as the former may wrap, but the latter
> cannot (assuming no overflow semantics for signed integer operations).
>
> Zdenek
>