[PATCH] Fix two bugs in gimple-fold.c and/or folding (PR tree-optimization/46909)

[Paul Koning]

On Dec 28, 2010, at 4:09 PM, Jakub Jelinek wrote:

> On Tue, Dec 28, 2010 at 04:03:28PM -0500, Paul Koning wrote:
>> 
>> On Dec 28, 2010, at 3:41 PM, Richard Guenther wrote:
>> 
>>> On Tue, Dec 28, 2010 at 8:27 PM, Paul Koning <paul_koning@dell.com> wrote:
>>>> I ran into an oddity with one of the testcases.
>>>> 
>>>> The one that scans the tree dump (gcc.dg/pr46909.c) fails for pdp11 because the tree dump file says it's checking for != 6 (which should be != 4).  But the generated code is correct.
>>>> 
>>>> Also curious is that the tree dump looks very different from the tree dump generated by the same rev compiler (give or take a few hours) on linux-x86.  Any idea what's going on here?
>>> 
>>> dependent on BRANCH_COST &&s and ||s will be lowered to control flow
>>> or and/ors.  You don't provide source to make the point about the
>>> !=6 vs !=4 issue.
>> 
>> The program being compiled is gcc/testsuite/gcc.dg/pr46909.c.  BRANCH_COST is constant 0 on the pdp11 target. 
> 
> If ifcombine optimizes the testcase into != 6 instead of != 4, then
> you are looking at what was happening before the fix.

That's what I thought too.  But I'm definitely using the fixed compiler.  It's freshly built from a sandbox updated today, and in any case the generated code shows the correct check (a compare with 4, not a compare with 6).

I went back and did some more checking.  It turns out that, on pdp11, it makes no difference whether the fix is in or not; it generates correct code either way, and it produces the tree dump file that I mentioned (which looks drastically different from the linux-x86 treedump).

I just did another fresh configure/build to make sure I didn't have a mixed-up build -- no, it was clean.

	paul