This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/83075] New: [8 Regression] Invalid strncpy optimization


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]