Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang emits memcpy for std::swap, which can introduce undefined behavior

llvm.org

Post reply on HN
Print view View original

11–20 of 83 posts

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#11

Post by boulos »

hendzen wrote: post #3

Specifically in the case of a self-swap, which is a somewhat odd thing to do in the first place.

Before shrink to fit, you could easily have produced this with a few references and a "use std::swap unconditionally".

The std::swap thing is only one pitfall, the reliance on "our memcpy will do the right thing with any overlap" is a bit risky (and doesn't hold with LD_PRELOAD, but I think it may have been switched to using the LLVM based librt project anyway, that is I'm not sure these calls are supposed to become naked memcpy).

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#12

Post by masklinn »

sgift wrote: post #7
steplee wrote: post #5

Aside: 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)

> How else should you pronounce it?

The official pronunciation is "klang" with a hard C: http://lists.llvm.org/pipermail/llvm-dev/2008-July/015629.ht...

Exactly like the metallic "clang" http://www.thefreedictionary.com/clang which originates from the latin clangere

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#14

Post by AnthonyMouse »

hendzen wrote: post #3

Specifically in the case of a self-swap, which is a somewhat odd thing to do in the first place.

It's quite common actually. Usually in the context of something like "swap element 'n' with the last element in this vector" without any check to see if 'n' is already the last element, because checking for that condition just to avoid a harmless no-op in the uncommon case is ugly and slower in the common case.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#15

Post by masklinn »

boulos wrote: post #9
steplee wrote: post #5

Aside: 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 ;)

The banging sound is also the one used by the developer team: http://lists.llvm.org/pipermail/llvm-dev/2008-July/015629.ht...

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#16

Post by wfunction »

nikic wrote: post #13

The bug report contains a quote from the C++ standard: "An rvalue or lvalue t is swappable if and only if t is swappable with any rvalue or lvalue, respectively, of type T" What does this statement mean and why is it not tautological?

It defines swappability of a single value in terms of swappability of a pair of values.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#17

Post by jahnu »

boulos wrote: post #9
steplee wrote: post #5

Aside: 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 ;)

Klang is also the German for "Sound"

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#20

Post by mehrdada »

The compiler causing undefined behavior on its own reminds me of one of the fun bugs we found[1] with 32-bit x86 clang where one compiler pass fools another into thinking there's an undefined behavior by combining three struct field initializations into a single 4-byte load, but the struct itself was 3-bytes long. Another pass looked at this and thought there's an undefined behavior writing past the struct boundary, silently eliminating the initialization altogether, resulting in bad codegen.

[1]: https://mehrdad.afshari.me/pubs/compiler-validation-via-equi...

Post reply on HN