Created attachment 22554 [details]
testcase

code example

Created attachment 22555 [details]
dumpspecs

gcc dumpspecs

Created attachment 22556 [details]
gcc version

Works for me on x86_64-darwin.

I am using an arm gcc cross-toolchain created with OpenEmbedded. Toolchain version and its dumpspecs are available in attachements. Wrong code for attached simple testcase is generated when I use -O2 optimization option. When optimization options are not used or when -O0 is in use then code is generated correctly. Running testcase is straightforward: compile an example with -O2 and without it, then run both examples (either on a suitable arm machine or under qemu) and get two different outputs (OK and WRONG) for two binaries.

This test case works for me on arm-linux-gnueabi with gcc-4.3.5 and gcc-4.4.6, but fails with current gcc-4.5.2 and gcc-4.6.

Confirmed.

*** Bug 46882 has been marked as a duplicate of this bug. ***

On trunk 

vrp converts the IR from :


<bb 3>:
  c_5 = D.2034_4;
  D.2026_6 = D.2034_4 == 13;
  D.2027_7 = D.2034_4 == 10;
  D.2028_8 = D.2026_6 || D.2027_7;
  if (D.2028_8 != 0)
    goto <bb 7>;
  else
    goto <bb 4>;

<bb 4>:
  D.2030_9 = D.2034_4 <= 31;
  D.2031_10 = D.2034_4 != 9;
  D.2032_11 = D.2030_9 && D.2031_10;
  if (D.2032_11 != 0)
    goto <bb 7>;
  else
    goto <bb 5>;

<bb 5>:
  str_12 = str_1 + 1;

<bb 6>:
  # str_1 = PHI <str_3(D)(2), str_12(5)>
  D.2034_4 = *str_1;
  if (D.2034_4 != 0)
    goto <bb 3>;
  else
    goto <bb 7>;

<bb 7>:
  # D.2033_2 = PHI <0(4), 1(6), 0(3)>
  return D.2033_2;


to

<bb 3>:
  c_5 = D.2034_4;
  D.2026_6 = D.2034_4 == 13;
  D.2027_7 = D.2034_4 == 10;
  D.2028_8 = D.2026_6 | D.2027_7;
  if (D.2028_8 != 0)
    goto <bb 7>;
  else
    goto <bb 4>;

<bb 4>:
  D.2030_9 = D.2034_4 <= 31;
  D.2031_10 = D.2034_4 != 9;
  D.2032_11 = D.2030_9 & D.2031_10;
  if (D.2032_11 != 0)
    goto <bb 7>;
  else
    goto <bb 5>;

<bb 5>:
  str_12 = str_1 + 1;

<bb 6>:
  # str_1 = PHI <str_3(D)(2), str_12(5)>
  D.2034_4 = *str_1;
  if (D.2034_4 != 0)
    goto <bb 3>;
  else
    goto <bb 7>;

<bb 7>:
  # D.2033_2 = PHI <0(4), 1(6), 0(3)>
  return D.2033_2;

After a while ifcombine comes along and removes basic block 5 and merges blocks 3 and 4 into 1 basic block because it thinks that the 


optimizing two comparisons to 1
Merging blocks 3 and 4
Removing basic block 5

and converts this to this form: 

<bb 2>:
  goto <bb 4>;


<bb 3>:
  D.2026_6 = D.2034_4 == 13;
  D.2027_7 = D.2034_4 == 10;
  D.2028_8 = D.2026_6 | D.2027_7;
  D.2030_9 = D.2034_4 <= 31;
  D.2031_10 = D.2034_4 != 9;
  D.2032_11 = D.2030_9 & D.2031_10;
  goto <bb 5>;

<bb 4>:
Invalid sum of incoming frequencies 873, should be 10000
  # str_1 = PHI <str_3(D)(2)>
  D.2034_4 = *str_1;
  if (D.2034_4 != 0)
    goto <bb 3>;
  else
    goto <bb 5>;

<bb 5>:
Invalid sum of incoming frequencies 10000, should be 873
  # D.2033_2 = PHI <0(3), 1(4)>
  return D.2033_2;

(In reply to comment #4)
> Works for me on x86_64-darwin.

Fails for me on x86_64 -linux with trunk as of today. 

Ramana

So the problem on trunk atleast seems to be in gimple-fold 

maybe_fold_or_comparisons and friends where all the comparisons are folded out into a single boolean node of 1 where ideally the result of the basic block should be reduced to the (c <= 31) && (x != 9) check . The other 2 equality comparisons are superfluous. 

I won't be able to look at this for a couple of days - hence unassigning myself.


The problem for this file goes away with -fno-tree-vrp but that's a heavy weight work around.



cheers
Ramana

Maybe dup of PR46909?

(In reply to comment #12)
> Maybe dup of PR46909?

I can verify that the fix for PR46909 fixes the issue on trunk.

I'm looking into 4.5 branch right now.


cheers
Ramana

It doesn't seem to fail for me with the RC for GCC 4.5.2

with -march=armv5te -mthumb
     -march=armv5te
     -march=armv7-a
     -march=armv7-a -mthumb

at -O2, -O3 and -Os

Fixed so closing as such.