https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Alexandre Oliva <aol...@gcc.gnu.org>: https://gcc.gnu.org/g:4505270128ef70538ea345f292e3eb85a5369eaf commit r13-4554-g4505270128ef70538ea345f292e3eb85a5369eaf Author: Alexandre Oliva <ol...@adacore.com> Date: Thu Dec 8 07:50:33 2022 -0300 [PR102706] [testsuite] -Wno-stringop-overflow vs Warray-bounds The bogus Wstringop-overflow warnings conditionally issued for Warray-bounds-48.c and -Wzero-length-array-bounds-2.c are expected under conditions that depend on the availability of certain vector patterns, but that don't seem to model the conditions under which the warnings are expected. On riscv64-elf and arm-eabi/-mcpu=cortex-r5, for example, though the Warray-bounds-48.c condition passes, we don't issue warnings. On riscv64-elf, we decide not to vectorize the assignments; on cortex-r5, we do vectorize pairs of assignments, but that doesn't yield the expected warning, even though assignments that should trigger the bogus warning are vectorized and associated with the earlier line where the bogus warning would be expected. On riscv64, for Wzero-length-array-bounds-2.c, we issue the expected warning in test_C_global_buf, but we also issue a warning for test_C_local_buf under the same conditions, that would be expected on other platforms but that is not issued on them. On arm-eabi/-mcpu=cortex-r5, the condition passes so we'd expect the warning in both functions, but we don't warn on either. Instead of further extending the effective target tests, introduced to temporarily tolerate these expected bogus warnings, so as to capture the vectorizer analyses that lead to the mismatched decisions, I'm disabling the undesired warnings for these two tests. for gcc/testsuite/ChangeLog PR tree-optimization/102706 * gcc.dg/Warray-bounds-48.c: Disable -Wstringop-overflow. * gcc.dg/Wzero-length-array-bounds-2.c: Likewise.
