https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94189
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:7afa3b82918a75a486aad7818f11df9ea7504368 commit r10-7206-g7afa3b82918a75a486aad7818f11df9ea7504368 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Mar 17 10:42:35 2020 +0100 expand: Don't depend on warning flags in code generation of strnlen [PR94189] The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't that we'd emit different code based on -g or non-debug, but rather that we emit different code depending on whether -w is used or not (or e.g. -Wno-stringop-overflow or whether some other pass emitted some other warning already on the call). Code generation shouldn't depend on whether we emit a warning or not if at all possible. The following patch punts (i.e. doesn't optimize the strnlen call to a constant value) if we would emit the warning if it was enabled. In the PR there is an alternate patch which does optimize the strnlen call no matter if we emit the warning or not, though I think I prefer the version below, e.g. the strnlen call might be crossing field boundaries, which is in strict reading undefined, but I'd be afraid people do that in the real world programs. 2020-03-17 Jakub Jelinek <ja...@redhat.com> PR middle-end/94189 * builtins.c (expand_builtin_strnlen): Do return NULL_RTX if we would emit a warning if it was enabled and don't depend on TREE_NO_WARNING for code-generation. * gcc.dg/pr94189.c: New test.
