https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #8 from Dmitry Vyukov <dvyukov at google dot com> --- On Tue, Jan 20, 2015 at 9:06 AM, vekumar at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 > > --- Comment #7 from vekumar at gcc dot gnu.org --- > (In reply to clyon from comment #6) >> Venkat, >> Can you submit your GCC patch, in an accepable way? (no change to sanitizer >> libs code, and obviously do not activate tsan by default) > > Okay I will send out a patch that modifies libsanitizer/configure.ac and > libsanitizer/tsan/Makefile.am that will separate out tsan_rtl_amd64.S from > getting build for other targets. > > > --- a/libsanitizer/tsan/tsan_rtl.h > +++ b/libsanitizer/tsan/tsan_rtl.h > @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr, uptr pc, > SyncClock *c); > // The trick is that the call preserves all registers and the compiler > // does not treat it as a call. > // If it does not work for you, use normal call. > -#if TSAN_DEBUG == 0 > +#if defined(__x86_64__) && TSAN_DEBUG == 0 > > This change is also acceptable? This change will be overwritten on the next integrate from upstream. Changes to runtimes need to go to llvm repo. However, in this case we just need to wait for mips64 change to be landed and it will fix this define as well.