2 ms·

I wonder if they'll get around to fixing this miscompliation bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 https://gcc.gnu.org/bugzilla/show_bug.cgi?i

• nullc 7y ago
  It isn't particularly helpful to downvote a comment to -3 without actually expressing what you found to be incorrect about it. I linked to an issue where all current GCC versions emits incorrect memory corrupting output from a pretty boring correct input which has been sitting idle for almost 4 months. The issue-- a morally similar issue of applying a constraint to the wrong scope-- was found in production code, in the wild-- it's not like its some machine generated test case. Currently the finders are working around it with -fno-stack-reuse but it's unclear how much other software is impacted... Should I be lobbying Linux distros to recompile everything with -fno-stack-reuse ? ... hard to say: there isn't an easy way to instrument the compiler to detect when the bug is being triggered. A rapid and highly knowledgeable response to miscompilation is what I've historically experienced from GCC and thats what's exhibited on the headline issue, but seemingly not in the case I linked to.
  • caf 7y ago
    That's definitely an interesting issue - I don't think it's too similar to the one in the original post, though. It's not about applying a constraint to the wrong scope, it's a case where the liveness analysis has correctly deduced that a block-scope variable in a loop is not live from one iteration of the loop to the next but then the address of that block-scope variable has been incorrectly kept live across the loop iterations.