opened 05:18PM - 03 Jun 24 UTC
bug
errata
## ⚠️ ADVISORY
Any systems using Nunavut generated C headers to deserialize m…essages when using aggressive optimizations with **GCC 12** through **GCC 13.2** should take this patch (when available) or should recompile their source using **GCC 13.3** or newer or, using their affected compiler, recompile with one of the following compiler options known to work around the issue:
- `-O2`
- `-O1`
- `-Og`
- `-finline-limit=200`
- `-fno-builtin-memmove`
## Details
`-O3` Optimized `memmove` code generated as part of large-function inlining appears to generate the wrong code on several platforms starting with GCC 12 until GCC 13.3 where it appears to be fixed. Based on the characteristics and timelines we believe this is a previously unobserved effect of a gcc tree-optimization bug "[110640, Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640)". Proofs of the reproduction for these compiler releases are shown here:
1. ✅ [GCC 11.4](https://godbolt.org/z/hns8z6fdd)
2. ⚠️ [GCC 12.1](https://godbolt.org/z/YPf4xjnMs)
3. ⚠️ [GCC 12.3](https://godbolt.org/z/9vP1qPjfK)
4. ⚠️ [GCC 13.2](https://godbolt.org/z/7doE8MM8a)
5. ✅ [GCC 13.3](https://godbolt.org/z/WKv4qa5dE)
For all reproductions `-O2` (or less, including `-Og`), `-finline-limit=200`, or `-fno-builtin-memmove` will work around the issue, however, `-fno-tree-vrp` does _not_ work around the issue as indicated by [110640](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640). This last observation makes it unclear if this issue is related to [110640](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640) but no other bug in this area of the compiler is found in the same compiler releases making us suspect this is an un-observed mode of that defect.
Using a slightly less complex case [here](https://godbolt.org/z/5834x4ed1) we can demonstrate the bug is avoided by adding a branching instruction before calling the memmove to avoid the failure to "no-op" zero-length move operations:
[proof of patch](https://godbolt.org/z/nWrc3dhTG)
Note - This bug was not found in any Clang version we tested. We believe Clang compilers are unaffected.