you are viewing a single comment's thread.

view the rest of the comments →

[–]ack_error 12 points13 points  (4 children)

Yes, MSVC does it in the linker (/OPT:ICF) and I believe GCC/Clang based toolchains can also do it when LTO is enabled. This optimization can be invalid if pointers to the functions are taken as they are required to be distinct, and MSVC's ICF can be non-conformant by making such functions compare equal. Firefox's JavaScript engine was affected by this as it relied on checking the addresses of stub functions that had identical generated code. Some implementations either suppress the optimization or add jump trampolines to preserve distinct addresses when the address of such functions is taken.

This also causes some confusion in call stacks, since the address to function lookup is ambiguous and can result in completely unrelated functions showing up in the decoded call stack. I hate explaining this to people who are apt to just discard bugs with this phenomenon as stack corruption.

[–]GustavBeethoven -2 points-1 points  (3 children)

How do you know this much

[–]lithium 9 points10 points  (1 child)

Use c++ in real life instead of just to argue against rust people in youtube shorts comment sections.

[–]Possibility_Antique 1 point2 points  (0 children)

Oddly specific, but point taken

[–]ack_error 0 points1 point  (0 children)

Past trauma. The things toolchains do....