[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Bug 84859 depends on bug 33315, which changed state. Bug 33315 Summary: stores not commoned by sinking https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 What|Removed |Added

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #12 from Richard Biener --- Author: rguenth Date: Mon Mar 19 14:08:58 2018 New Revision: 258645 URL: https://gcc.gnu.org/viewcvs?rev=258645=gcc=rev Log: 2018-03-19 Richard Biener PR

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #10 from Richard Biener --- Created attachment 43674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43674=edit patch Final patch I am testing.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #9 from Richard Biener --- Like moving over a const call after the stores might cause us to spill across the call. Moving over any stmt could enlarge lifetimes enough to do that. Register lifetime could be so that we cannot

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Richard Biener changed: What|Removed |Added Depends on||33315 --- Comment #7 from Richard

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #6 from Martin Sebor --- We have seen this sort of thing come up a number of times in the past. Jeff and I have discussed changing jump threading to either avoid introducing paths involving invalid calls, or inserting

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #5 from Jakub Jelinek --- Seems the kernel testcase is actually more like: void f (void*); void __attribute__ ((noinline, noclone)) g (const void *p, unsigned n) { unsigned char a[8]; if (n > sizeof a - 1) return; for (;

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #3 from Martin Sebor --- The warning is in response to the call to memcpy(d, s, 255) in h(): [local count: 477815112]: a[0] = 255; __builtin_memcpy (, p_15(D), 255); _26 = a[0]; The wording seems clear: The function is

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 --- Comment #4 from Jakub Jelinek --- Note, even teaching VRP to look through stores and loads from memory wouldn't help here, not even for the first function, because it uses *a as the length, but also overwrites it (potentially or for real)

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84859 Richard Biener changed: What|Removed |Added Keywords||missed-optimization