rsmith added a comment. In D79279#2197176 <https://reviews.llvm.org/D79279#2197176>, @rjmccall wrote:
> I thought part of the point of `__builtin_memcpy` was so that C library > headers could do `#define memcpy(x, y, z) __builtin_memcpy(x, y, z)`. If so, > the conformance issue touches `__builtin_memcpy` as well, not just calls to > the library builtin. They would have to declare it as well (because C code can `#undef memcpy` and expect to then be able to call a real function), so the `#define` would be pointless. It doesn't look like glibc does anything like this; do you know of a C standard library implementation that does? If we want to follow that path, then we'll presumably (eventually) want address-space-`_overloaded` versions of all lib builtins that take pointers -- looks like that's around 60 functions total. That said, I do wonder how many of the functions in question that we're implicitly overloading on address space actually support such overloading -- certainly any of them that we lower to a call to a library function is going to go wrong at runtime. +@tstellar, who added this functionality in r233706 -- what was the intent here? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79279/new/ https://reviews.llvm.org/D79279 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
