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.