[Bug tree-optimization/91616] Incorrect data address computation in very simple code

[mpoulhies at kalray dot eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91616

--- Comment #3 from Marc POULHIÈS  ---
Ok, sorry for the incorrect report.

The problem was found in our port of GCC where the code actually really
accesses an incorrect memory location and seeing this very large offset added
to data array lead me to an incorrect conclusion.

You can close this PR.

[Bug tree-optimization/91616] Incorrect data address computation in very simple code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91616

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-02
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I don't see anything "incorrect" either - GCC optimizes this down to the
single IV 'seed', eliding 'i' by expressing data_array[i] in terms of 'seed':

   [local count: 955630224]:
  # seed_14 = PHI <14627338366734941935(2), seed_7(3)>
  seed_7 = seed_14 + 1;
  MEM[symbol: data_array, index: seed_7, step: 8, offset:
-633824249165792B] = seed_14;
  if (seed_7 != 14627338366734941951)
goto ; [89.00%]

[Bug tree-optimization/91616] Incorrect data address computation in very simple code

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91616

--- Comment #1 from Mikael Pettersson  ---
Please provide a self-contained test case with a built-in check of its
correctness, or at least a printout of the computed array.  I did the latter
locally, and data_array[] looks correct to me (it contains 0xcafebebedeadbeef
up to 0xcafebebedeadbefe as one would expect from the source code).