Fix wrong-code bug caused by combine_simplify_rtx()

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>> Mark Mitchell <mark@codesourcery.com> writes:
>>>Richard Sandiford wrote:
>>>>The patch below simply removes this transformation.  In order to get
>>>>some idea of the performance impact, I compared the before-and-after
>>>>-O2 assembly output of gcc.c-torture and gcc.dg for three targets:
>>>>    i686-pc-linux-gnu
>>>>    powerpc-eabisim
>>>>    mips64-elf
>>>>In all three cases, only the output for the new testcase changed.
>>>>There were no differences in the code generated for the other tests.
>>>>Bootstrapped & regression tested on i686-pc-linux-gnu.  OK for
>>>>mainline?
>>>
>>>OK, assuming no objections in 24 hours.

[Now committed to mainline, btw]

>> Thanks.  For 4.0 too, or just mainline?
> Both, if it's a regression; otherwise, just mainline.

Well, the original justification for asking about 4.0 was:

    The code in question has been around since 1992, so this is hardly a
    regression in that sense.  It is the kind of thing that could trigger
    in different cases for different releases though, [...]

So, for example, you can construct test cases that fail because
we now inline once-used statics into their callers.  E.g.:

    static int foo (int x) { return (signed char) (x - 100); }
    int __attribute__((noinline)) bar (int x) { return foo (x) - 5; }
    int main (void) { if (bar (200) != 95) abort (); exit (0); }

This testcse used to work when compiled with gcc 3.3 at -O2 but doesn't
with 4.0.  The same is true without the noinline attribute if you put
foo() and bar() in a different CU from main().

Is that good enough, or too cheesy?  Also, what about the branch freeze?
Should I wait until the prerelease has been spun?

Richard