search for: __memset_chk

Hi all, Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend and the C backend I see it converting regular (non-checking) memcpy and memset calls to __memset_chk and __memcpy_chk already at the IR stage. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc builtin function. This way the resulting C code is usable as-is only on gcc-compatib...

> Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend > and the C backend I see it converting regular (non-checking) memcpy and > memset calls to __memset_chk and __memcpy_chk already at the IR stage. Most probably these are changed due to defines in the system headers, so, compiler cannot do anything about this. You can hack on your system headers though. > In a similar manner, llvm.objectsize.* calls are replaced with > __builtin_object_size cal...

...l ======== The following three sections specify a proposal for how the work will be broken down. In a way they specify milestones. Extend test coverage -------------------- Between the two existing methods the following library calls are folded: 1. `InstCombiners`: __memcpy_chk, __mempcpy_chk, __memset_chk, __strcpy_chk, __stpcpy_chk, __strncpy_chk, __stpncpy_chk, __strcat_chk, __strncat_chk. 2. `SimplifyLibCalls`: strcat, strncat, strchar, strrchr, strcmp, strncmp, strcpy, strncpy, strlen, strpbrk, strtol, strtod, strtof, strtoul, strtoll, strtold, strtoull, strtold, strtoull, strspn, str...