https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Tim Ruffing <public at timruffing dot de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |public at timruffing dot de --- Comment #17 from Tim Ruffing <public at timruffing dot de> --- Created attachment 49276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49276&action=edit Hacky patch that makes GCC print a diagnostic message if hitting the bug We hit this bug in a test case in secp256k1, the cryptography library used in Bitcoin Core. The bug appeared pretty scary to us at first glance because memcmp is widely used. After looking at the GCC patch that fixes this, we believe that this bug only occurs when * at least one of the compared byte arrays is constant and has a zero byte in position 0, 1, 2, or 3, *and* * the result of the memcmp isn't immediately used in a "== 0" or "!= 0" test (or equivalently "if(memcmp(...))" or "if(!memcmp(...))"). In particular the second condition makes this bug pretty rare and explains why it's mostly hit in non-inlined memcmp wrappers. (But in our case we hit it with a "<" comparison. ) For anyone else who's concerned about this bug, we've created a hacky patch (co-authored by Russell O'Connor) for the GCC versions with this bug that makes GCC print a diagnostic message if it emits wrong code due to this bug. We think the message is sound but it would be great if someone could confirm this.