• Work on "mix testing"：Luke Geeson 与他人合作的“混合测试”工作将在 10 月的 OOPSLA 2024 上发表。“litmus 测试”在过去几十年有很多研究，通常是生成大量小并发程序，输入编译器后看编译代码在目标机器上执行是否正确，而 Luke 的想法是将 litmus 测试拆分成小片段，由不同编译器编译，以发现编译器之间意外交互导致的错误。
• Example of "mixing bug" on x86：以针对 x86 架构的“存储缓冲”litmus 测试为例，C 标准要求执行两个线程后，t 和 u 的值不能都为 0，但朴素编译到 x86 时不满足要求，因为 x86 处理器遇到写后读不同位置时不保证顺序，编译器需插入屏障。有在每个写后插入屏障和在每个读前插入屏障两种方案，前者更常用，主要编译器 GCC 和 Clang 采用，但两种方案需一致，混合使用会导致编译器错误假设而不插入屏障。
• Real "mixing bug" on Arm：以相同的“存储缓冲”litmus 测试在 Arm 上编译为例，Clang 为 Armv7 架构编译时在所有四个指令序列末尾插入屏障，为 Armv8 架构编译时利用 Armv8 新特性避免屏障，更高效。但如果第一个线程指令用 Armv8 编译，第二个线程指令用 Armv7 编译，两种机制都不起作用，因为 Armv7 依赖写后插入屏障，Armv8 没有此屏障，导致存储和加载可能被重新排序，出现编译器错误。
• Luke's tool and future work：Luke 构建了一个工具，探索每个 litmus 测试的多种编译器组合，发现了上述类似的几个错误，目前该错误仍未解决。他正与 Arm 的同事合作，使 ABI 更明确各种编译方案何时可以安全混合，希望为未来的混合编译提供更坚实的基础。此工作得到工程和物理科学研究委员会的支持，博客中的观点不代表 Arm 或其他提及公司的立场。