Thanks for the interesting case. I guess many readers have read too much into lt2 and lt3 but overlooked the code under 2.4.2: C++ could actually be that bad. In that code, you only showed the timing in comments. The result may be worth a table. Perhaps another way to structure the manuscript is to give the surprising result of 2.4.2 first and then to explain what makes that happen.
At my previous job a colleague showed me some C++ code and asked if I could help him spot the issue. I looked at it and said it looked fine. He ran the program and it crashed.
We ended up staying late in order to try to find a minimal reproducible example. We finally managed and found that the cause was a basic trigonometric function in the standard library giving the wrong result.
At first, we couldn't believe it. Then we googled the issue and found a bug report about the intrinsic version of that function not working properly. With Microsoft confirming that it didn't and that they weren't looking to fix it. We disabled intrinsics in that section of the code and the original code worked as intended.
I encountered two or three compiler bugs within weeks of starting to (seriously) work with C++. And one of them was as simple as enabling lto caused GCC to segfault.
> certain C/C++ variables can shape-shift for a thousandth of a second, transiently morphing into alternative states that can allow the program to crash or produce an incorrect result
I thought there was a difference between a C and C++ implementation, but it was an error on my part. When I fixed the bug, I changed the post title. But the post hit HN while I was in the process of fixing it.
It's indeed not a bug for C++, but to be clear it is a bug for C and Rust that use LLVM but don't have that same guarantee as C++. LLVM assumes that guarantee holds for all frontends, and added the sideeffect opcode so that frontends for languages that don't have that guarantee have a way out.
This looks to be an assertion failure, i.e. code that was thought to be unreachable is not. So there's no evidence that any of the negatives of C++ (memory safety, etc.) are in play here.
The author makes it sound like a warning label is missing from the C++ tin. Maybe. But what tool should he have used? I haven't seen this code but is there any doubt it would look just as bad in Java or Python, maybe with fewer segfaults? Or FORTRAN.
This bug is really, really subtle. The repro that was posted that just tries to stress this bug can take hours to deadlock on some machines. Confirming that you've fixed it properly is a bit harrowing.
Even as an OCaml snob I haven't a clue how you would verify the behavior of this C library formally.
Yeah, after reading the blog post I felt reasonably confident that this is a compiler bug (in terms of perf).
Hopefully someone with a deeper understanding can verify or discredit this here. I'm curious to see the fix for this (I assume it will generate a fix).
I spent at least an hour a while ago trying to track down a bug that turned out to be caused by exactly this. I couldn't work out what was happening until I looked at the preprocessor output.
reply