Recent searches
Search options
Sometimes it takes more time to refute a `gcc` bug than confirm it. This week I spent most time on https://gcc.gnu.org/PR114872 where `sagemath` `SIGSEGV`ed on some simple inputs.
Bug updates are a bit hard to read and are missing a bit of compiler-unrelated context. I wrote something more coherent in https://trofi.github.io/posts/312-the-sagemath-saga.html
@trofi Sad fact: we unsuccessfully attempted to upstream a GCC patch that would warn about this. The idea was exactly that you can get a warning *before* upgrading the compiler breaks the code. Our current iteration of that patch produces 142 warnings on that testcase from the GCC Bugzilla.
@amonakov Oh, that's unfortunate :(
Out of idle curiosity: did your change analyze the program before or after `gcc` optimization passes (or both?) when detecting such rule violations?
I wonder if `gcc` could introduce problematic variable clobbers (like stack reuse) where there are none at the source level and whether you ever saw anything like that. It feels like `gcc` could break programs this way, but I did not try to construct the example.
@trofi re first question: in the middle :)
re the second: if I understand the question correctly, that would be a compiler bug, and so far I've seen that just once (the bug being marked a dup is somewhat incorrect but I was tired of arguing): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
@trofi by the way, the existing -Wclobbered warning already produces 73 warnings for that testcase in gcc-13 (the existing warning detects a subset of violations, but tends to report cases where the compiler did, in fact, likely break the code)
@amonakov TIL about the `-Wclobbered`! Shamelessly added as https://github.com/trofi/trofi.github.io.gen/commit/e6a62e85f8534a410cb328aeccb00fd6c102cca9 as well. Thank you!