This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/83075] New: [8 Regression] Invalid strncpy optimization
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 20 Nov 2017 17:07:16 +0000
- Subject: [Bug tree-optimization/83075] New: [8 Regression] Invalid strncpy optimization
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83075
Bug ID: 83075
Summary: [8 Regression] Invalid strncpy optimization
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
handle_builtin_stxcpy has:
/* Strncpy() et al. cannot modify the source string. Prevent the rest
of the pass from invalidating the strinfo data. */
if (sisrc)
sisrc->dont_invalidate = true;
and I believe that is just wrong. Consider following testcase:
typedef __SIZE_TYPE__ size_t;
size_t
foo (char *p, char *q)
{
size_t l1 = __builtin_strlen (q);
__builtin_strncpy (p, q, l1);
size_t l2 = __builtin_strlen (q);
return l1 + l2;
}
int
main ()
{
char buf[16] = "abcdef";
if (foo (buf + 6, buf) != 6 + 12)
__builtin_abort ();
return 0;
}
The C99 standard says here:
The strncpy function copies not more than n characters (characters that follow
a null character are not copied) from the array pointed to by s2 to the array
pointed to by s1. If copying takes place between objects that overlap, the
behavior is undefined.
It specifically talks about 2 arrays, not about strings, and I believe there
is no overlap above, the source is the first 6 characters, the destination
starts after that. So IMHO we aren't allowed to optimize away the second
strlen call.