[LLVMbugs] [Bug 12909] New: builtin memcpy behaviour compared to gcc when destination unknown ...
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue May 22 01:57:38 PDT 2012
http://llvm.org/bugs/show_bug.cgi?id=12909
Bug #: 12909
Summary: builtin memcpy behaviour compared to gcc when
destination unknown...
Product: clang
Version: 3.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: viswabramana.rajesh at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 8615
--> http://llvm.org/bugs/attachment.cgi?id=8615
library calls file
__builtin_memcpy_chk function optimization O123 behaviour in clang.
I have noticed in clang for builtin __memcpy_chk function when destination
buffer unknown than, builtin calls optimized to direct memcpy.
Where as if destination has known pointer at compilation time than it will call
builtin mem_chk function which in turn calls memcpy.
Test code:
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
extern void *memcpy (void *, const void *, size_t);
#define memcpy(dst, src, len) \
__builtin___memcpy_chk (dst, src, len, __builtin_object_size (dst, 0))
int l1 = 1;
int chk_calls;
int main ()
{
char *s3 = "FGH";
char *r;
char buf1[10], buf2[10];
chk_calls = 0;
memcpy(buf1, s3, l1); // Destination is known(buf1), length is not known
calls memcpy_chk
r = l1 == 1 ? buf1 : buf2;
memcpy(r, s3, l1 + 1); // Destination not known, clang optimizing call to
memcpy
if (chk_calls != 2)
abort ();
}
Above test code along with attached libcalls.c,when run in gcc with
optimizaiton O123 test code passes.
Same set of code when run in Clang(O123) its aborted, since second builtin
memcpy call optimized to direct memcpy function and chk_calls not incremented
to 2
Optimizing builtin memcpy function when destination buffer is unknown, Is it
Accepted behaviour?
-viswa
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list