07:15 MrCooper: kode54: building Mesa with LTO can appear to work fine, until it suddenly blows up in your face for no apparent reason
07:15 MrCooper: nobody has been able to identify any factor which makes the difference
07:27 kode54: Oh look what they just did
07:27 kode54: https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/commit/c3e9f807291589f75da76aa9ecabe59818139f95
07:27 kode54: 🙃
11:40 Venemo: kode54: the problem is that the gcc devs blame mesa and are not really cooperative in investigating what is wrong with lto (I asked them once)
13:45 orbea: i wonder if ubsan could figure out what is wrong?
18:23 kode54: Venemo: wow
19:17 Venemo: kode54: wow what?
19:17 Venemo: orbea: maybe. I never tried
19:23 kode54: Venemo: no, I mean, I think it's dumb that GCC just outright blames mesa
19:24 kode54: sure, it's the code's fault that the compiler breaks it
19:24 kode54: and only when hyper optimizing
19:26 orbea: kode54: depends why it break, if mesa is depending on UB that happens to break with LTO then it should probably be fixed in mesa
19:26 kode54: true
19:26 kode54: I guess that's a hard thing to track down, though
19:27 orbea: ubsan can catch these sometimes
19:27 kode54: (no, really, I know it is)
19:27 kode54: ah, ubsan, that is sometimes helpful
19:27 orbea: try running the CI with ubsan using both gcc and clang, that might find something?
19:27 kode54: hmm
19:34 Venemo: kode54: the problem is that these LTO issues are completely nonsensical, not bisectable, and there is no tool that is guaranteed to detect them
19:35 Venemo: there is no way without putting in immense effort to prove whose fault it is
19:38 pendingchaos: I wonder if we could somehow incrementally switch from not-LTO to LTO
19:38 pendingchaos: might help track down which file/function is problematic
20:07 kode54: Venemo: gotcha
20:07 kode54: it's probably also a pretty bad idea to globally enable LTO in default package build settings
20:08 kode54: (that's the Arch defaults)