https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- >> (In reply to r...@cebitec.uni-bielefeld.de from comment #9) [...] >> If it works, nice. Can you file it on github.com/llvm/llvm-project as an >> issue >> and see if upstream is willing to accept it? I think they'll want some > > Can do, either as an issue or directly as a pull request. I'll run it > through a full llvm build, too, first. Unfortunately, this didn't work out at all. Initially, I had only rebuilt libsanitizer with the patch, checking that there were only the exepected number of calls to mem* functions in libasan.so. The LLVM build on Solaris/sparcv9, while successful, doesn't tell you much, unfortunately: due to a clang bug on sparc, the asan tests are never run there. When I ran a full Solaris/SPARC bootstrap, all asan tests FAILed with AddressSanitizer: CHECK failed: asan_rtl.cpp:397 "((!AsanInitIsRunning() && "ASan init calls itself!")) != (0)" (0x0, 0x0) (tid=1) I've once had the misfortune of debugging such a initializion order issue in LLVM, and that was an long and painful experience which I'd rather not repeat here. The fix found in that case (build both libasan.so and all asan tests with -z now) didn't work here, either: this just turned the assertion failures into SEGVs. This reliance on init order is a total nightmare: the details are completely platform-specific and not portable at all. Given all this, I've instead developed a patch that checks for assembler a = b support in the libsanitizer configury and uses the result in sanitizer_redefine_builtins.h. This way, only the one configuration that has an issue here is punished. However, this has to stay local to libsanitizer for obvious reasons.
