Per VognsenWeird FUD by Phoronix about LTO builds since Mesa is apparently turning off their LTO builds due to "impossible to reproduce bugs that only happen in LTO builds". I'd like to get other people's take, but I'm assuming what's actually happening is that like with -O1 vs -O3, optimizing across translation units is exposing latent UB bugs (or much less likely, latent compiler bugs not directly related to LTO), and it's not that the LTO pass itself is buggy.
With the right adjustment in your mindset, any time you find that a bug with your code only materializes with different compilers or compiler versions or optimization flags, you're given a gift that lets you root out UB bugs in your code. Or, much more rarely, you get to root out compiler bugs, which is less fun. But having been in the situation of trying to ship things with latent UB like this, I understand the frustration. So don't ship LTO for now, but you (probably) still have serious bugs.
If you're a real psychopath you can try to fuzz your code for UB by compiling and auto-testing it with many different permutations of compilers and compiler configurations like that.
Josh Simmons@pervognsen also if you have a reproducible issue it's probably worth reaching for `-fwrapv` and `-fno-strict-aliasing` first, since that might help you narrow it down more than reaching for the hammer that is disabling LTO.
the tower fairy@dotstdy @pervognsen fwiw it's no help when the compiler is rustc. For that one you do need the deranged fuzzing mentioned above ðŸ«
@crystalmoon @pervognsen at least there's still no tbaa!
@dotstdy @pervognsen but you have non-deduplicable Comdat sections ðŸ˜