Clang emits memcpy for std::swap, which can introduce undefined behavior
1–10 of 83 posts
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#2IIRC, there are passes that also detect memcpy-"equivalent" loops and replace them with the builtin to memcpy (mostly to get the vectorization benefit). And of course there's SimplifyLibCalls (or whatever it's named) that undoes this or any other "you called a standard library function we know how to inline in this case".
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#3Specifically in the case of a self-swap, which is a somewhat odd thing to do in the first place.
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#4IIRC, there are passes that also detect memcpy-"equivalent" loops and replace them with the builtin to memcpy (mostly to get the vectorization benefit). And of course there's SimplifyLibCalls (or whatever it's named) that undoes this or any other "you called a standard library function we know how to inline in this case".
The second one sounds like big fun when you LD_PRELOAD a different memcpy (say, for debugging purposes) and spend hours and hours trying to figure out why it is not being called.
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#5Aside: am i crazy for pronouncing clang see-lang in my head?
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#6IIRC, there are passes that also detect memcpy-"equivalent" loops and replace them with the builtin to memcpy (mostly to get the vectorization benefit). And of course there's SimplifyLibCalls (or whatever it's named) that undoes this or any other "you called a standard library function we know how to inline in this case".
The second one sounds like big fun when you LD_PRELOAD a different memcpy (say, for debugging purposes) and spend hours and hours trying to figure out why it is not being called.
Yes, it's a nightmare, particularly on OS X with its funny loader semantics that make replacing malloc and free correctly very painful. For example, you can easily LD_PRELOAD your way out of malloc() but did you remember that asprintf also calls an allocation routine and won't use your new malloc? Enjoy.
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#7Aside: am i crazy for pronouncing clang see-lang in my head?
How else should you pronounce it? (i.e. I do this too, never thought about it before)
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#8IIRC, there are passes that also detect memcpy-"equivalent" loops and replace them with the builtin to memcpy (mostly to get the vectorization benefit). And of course there's SimplifyLibCalls (or whatever it's named) that undoes this or any other "you called a standard library function we know how to inline in this case".
The second one sounds like big fun when you LD_PRELOAD a different memcpy (say, for debugging purposes) and spend hours and hours trying to figure out why it is not being called.
GCC does the exact same thing, and it can be turned off with -fno-builtin.
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#9Aside: am i crazy for pronouncing clang see-lang in my head?
No, you're not crazy. Some people definitely pronounce it C-lang, while others produce a banging sound (klang). I prefer the banging sound ;)
Re: Clang emits memcpy for std::swap, which can introduce undefined behavior
#10Given how aggressively compilers (including Clang) are exploiting undefined behavior these days, it is surprising to see Clang developers (I presume) on the bug being so blasé about introducing undefined behavior themselves.