https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-12-14
CC| |rguenth at gcc dot gnu.org
Blocks| |49774
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
_33 = MEM[(double *)_28 clique 1 base 2];
MEM[(double *)_32 clique 1 base 2] = _33;
_35 = MEM[(double *)_28 + 8B clique 1 base 2];
MEM[(double *)_32 + 8B clique 1 base 2] = _35;
_49 = MEM[(double *)_28 clique 1 base 2];
MEM[(double *)_32 clique 1 base 2] = _49;
_51 = MEM[(double *)_28 + 8B clique 1 base 2];
MEM[(double *)_32 + 8B clique 1 base 2] = _51;
t.c:13:24: note: can't determine dependence between MEM[(double *)_32 clique 1
base 2] and MEM[(double *)_28 + 8B clique 1 base 2]
As you can see we do not exploit that n != k when assigning restrict tags
to the indirect loaded pointers. Nor would we do that when you load
those in an unrolled loop. Our restrict machinery is simply not set up
for this.
I don't see how a compiler could reliably and reasonably implement this.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues
