Somewhere in the range 177b800f5fc861af1bf8700f050de28dd47ee1aa, r12-4288 to 338725652f84793805c55f08a7607c2f45d5512b, r12-4320 these tests started failing. For some reason git bisect isn't pointing me to the right revision, though. FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++14 scan-tree-dump-not optimized "goto" FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++17 scan-tree-dump-not optimized "goto" FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++2a scan-tree-dump-not optimized "goto" FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++2a (test for excess errors) FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++98 scan-tree-dump-not optimized "goto" FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++98 (test for excess errors)
This was known to happen, see r12-4319 .
Yes, sorry for that.
Oh, I can probably fix the FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++17 scan-tree-dump-not optimized "goto" since the expected optimization is not valid. But the IMHO bogus excess error remains, see PR101480 for an analysis. Quote: -- What we see is the global variable construction function which accesses just 'a', and yes, the call to 'new' is considered clobbering global variables (including 'a'): <bb 2> [local count: 1073741824]: MEM[(struct __as_base &)&a] ={v} {CLOBBER}; a.m = 0; _5 = operator new [] (0); a.p = _5; goto <bb 4>; [100.00%] <bb 3> [local count: 8687547547]: _7 = (long unsigned int) i_6; _8 = _7 * 4; _9 = _5 + _8; MEM[(int *)_9] = 0; i_10 = i_6 + 1; <bb 4> [local count: 9761289362]: # i_6 = PHI <0(2), i_10(3)> _11 = a.m; if (i_6 < _11) goto <bb 3>; [89.00%] else goto <bb 5>; [11.00%] <bb 5> [local count: 1073741824]: return; I suppose implementing the global operator new as accessing a.m would be valid as IIRC lifetime of a starts when the CTOR is invoked, not when it finished (otherwise the CTOR could not access the variable itself). We somehow conclude that _9: void * [1B, +INF] EQUIVALENCES: { } (0 elements) possibly because it cannot be NULL (?): extract_range_from_stmt visiting: _5 = operator new [] (0); Found new range for _5: void * [1B, +INF] marking stmt to be not simulated again (huh?) and then the -Warray-bounds warning concludes the access is always outside of the allocated area. I suspect when we'd arrive at VARYING we'd not issue the warning even when the access would always extend beyond a zero-sized allocation. --
Was the change that caused this backported to gcc 11? I am seeing the same failures there now.
It was backported here: g:19dcea67ac40cfdeb396fa264ebbe04fbe61fdc0
Yes. Whatever solution we find for the testcase needs to be backported as well.
So can we XFAIL it in the meantime, especially on the 11 branch?
(In reply to Eric Botcazou from comment #7) > So can we XFAIL it in the meantime, especially on the 11 branch? Let me do that.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:b2cd32b743ba440e75505ce30c6b5c592ed144ea commit r12-5107-gb2cd32b743ba440e75505ce30c6b5c592ed144ea Author: Richard Biener <rguenther@suse.de> Date: Wed Nov 10 11:08:03 2021 +0100 testsuite/102690 - XFAIL g++.dg/warn/Warray-bounds-16.C This XFAILs the bogus diagnostic test and rectifies the expectation on the optimization. 2021-11-10 Richard Biener <rguenther@suse.de> PR testsuite/102690 * g++.dg/warn/Warray-bounds-16.C: XFAIL diagnostic part and optimization.
The releases/gcc-11 branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:3dea90505df136a4b361665772ef8e62306cfcdb commit r11-9233-g3dea90505df136a4b361665772ef8e62306cfcdb Author: Richard Biener <rguenther@suse.de> Date: Wed Nov 10 11:08:03 2021 +0100 testsuite/102690 - XFAIL g++.dg/warn/Warray-bounds-16.C This XFAILs the bogus diagnostic test and rectifies the expectation on the optimization. 2021-11-10 Richard Biener <rguenther@suse.de> PR testsuite/102690 * g++.dg/warn/Warray-bounds-16.C: XFAIL diagnostic part and optimization. (cherry picked from commit b2cd32b743ba440e75505ce30c6b5c592ed144ea)
XFAILed. I still think the diagnostic should be fixed.
> XFAILed. I still think the diagnostic should be fixed. This works fine on the 11 branch, thanks!
GCC 11.3 is being released, retargeting bugs to GCC 11.4.
The master branch has been updated by Kito Cheng <kito@gcc.gnu.org>: https://gcc.gnu.org/g:0f6eef398045deb2a62d18b526831719c7c20c8a commit r13-1357-g0f6eef398045deb2a62d18b526831719c7c20c8a Author: Kito Cheng <kito.cheng@sifive.com> Date: Tue Jun 28 18:43:42 2022 +0800 testsuite/102690: Only check warning for lp64 in Warray-bounds-16.C That warning won't happen on ilp32 targets, seems like Andrew Pinski already mention that[1] before. Verified on riscv32-unknown-elf and riscv64-unknown-elf. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879#c1 gcc/testsuite/ChangeLog: PR testsuite/102690 * g++.dg/warn/Warray-bounds-16.C: XFAIL only on lp64 for the warning.
GCC 11.4 is being released, retargeting bugs to GCC 11.5.
GCC 11 branch is being closed.