[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Bug 66974 depends on bug 83202, which changed state. Bug 83202 Summary: Try joining operations on consecutive array elements during tree vectorization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Depends on||83202 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed on trunk. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202 [Bug 83202] Try joining operations on consecutive array elements during tree vectorization
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Dec 14 15:18:16 2017 New Revision: 255642 URL: https://gcc.gnu.org/viewcvs?rev=255642&root=gcc&view=rev Log: 2017-12-14 Richard Biener PR tree-optimization/66974 * gcc.dg/Warray-bounds-24.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-24.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- Also fixed by loop header copying.
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 --- Comment #5 from Ganesh Ajjanagadde --- That I do not consider a readable or scalable solution. Furthermore, this is a bug, and the FFmpeg codebase gets compiled across a wide array of compilers. We can't insert hacks for specific GCC versions. Thanks for pointing it out nonetheless.
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- (In reply to Ganesh Ajjanagadde from comment #2) For what it's worth, telling gcc that the argument is constrained to the limited range of values either by converting it like so: order = ((struct { unsigned order: 2; }){ order }).order; or by declaring the function to take an argument of that type eliminates the warnings and results in far simpler object code.
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- The reason seems to be that GCC unrolls the inner loop completely to something like: if (i / 2 != 0) { // i > 1 c[0] += c[i] * c[i-1]; c[i-1] += c[i] * c[0]; if (i / 2 > 1) { // i > 3 c[1] += c[i] * c[i-2]; c[i-2] += c[i] * c[1]; if (i / 2 > 2) { // i > 5 c[2] += c[i] * c[i-3]; c[i-3] += c[i] * c[2]; } } } by reasoning that j < 3. However, it is not able to remove the two inner conditions by reasoning that i < 3 Since i's upper-bound depends on order and order is a parameter, it should be able to assume it (or at least say "may be above"). Interestingly, if one changes the function to: int foo(unsigned order) { int c[3] = {1, 2, 3}; if (order >= 5) return 0; unsigned i, j; for (i = 1; i < order; i++) { for (j = 0; j < i / 2; j++) { c[j] += c[i] * c[i-j-1]; c[i-j-1] += c[i] * c[j]; } } return c[0]; } There is an out-of-bounds access that is not detected by -Warray-bounds, but it is detected by -Wuninitialized: test.c:7:16: warning: ‘c[3u]’ may be used uninitialized in this function [-Wmaybe-uninitialized] c[j] += c[i] * c[i-j-1]; ^
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 --- Comment #2 from Ganesh Ajjanagadde --- Of course. However, the caller might ensure that order is always in the valid range (e.g <= 3 in this case), and the callee should not have to verify this if that is the case. The reason we do not actually do the check is because it is in performance critical code (note test case is simplified and does not convey how critical it is, which can only be seen from interactions with larger codebase). As per manual, --- -Warray-bounds -Warray-bounds=n This option is only active when -ftree-vrp is active (default for -O2 and above). It warns about subscripts to arrays that are always out of bounds. This warning is enabled by -Wall. -Warray-bounds=1 This is the warning level of -Warray-bounds and is enabled by -Wall; higher levels are not, and must be explicitly requested. -Warray-bounds=2 This warning level also warns about out of bounds access for arrays at the end of a struct and for arrays accessed through pointers. This warning level may give a larger number of false positives and is deactivated by default. -- Thus, -Warray-bounds should not flag unless the compiler is certain about the out of bounds nature. Here the compiler can't do that, and should not give a false positive. For the sake of argument, suppose it should flag this. Then -Warray-bounds is not terribly useful, since much simpler code (below) does not trigger the warning under same flags: -- int foo(unsigned order) { int c[3] = {1, 2, 3}; unsigned i; for (i=1; i < order; i++) c[i] += c[i/2]; return c[0]; } --
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #1 from DJ Delorie --- If elsewhere calls foo(500) you will get an actual out of bounds access. I think the warning is appropriate. Have you tried checking the value of 'order' in that function, before the loop, to validate its value? Such a check might fix your bug and silence the warning.