Hi Jakub, I committed the patch with the change log corrections you said.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034 regards, Venkat. On 23 January 2015 at 02:14, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote: >> On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: >> >> ping. >> >> >> >> Forgot to mention, GCC bootstraps and regression testing passed on x86_64. >> > >> > Well, without a change from upstream to guard the HACKY_CALL and actual >> > tsan >> > port to non-x86_64 this patch doesn't solve anything. >> >> >> I've just committed that change upstream: >> http://llvm.org/viewvc/llvm-project?view=revision&revision=226829 >> Now we need to summon +Kostya to update gcc version of runtime. > > Here is what I've committed: > > 2015-01-22 Jakub Jelinek <ja...@redhat.com> > > * tsan/tsan_rtl.h: Cherry pick upstream r226829. > > --- libsanitizer/tsan/tsan_rtl.h (revision 226828) > +++ libsanitizer/tsan/tsan_rtl.h (revision 226829) > @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr > // 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 TSAN_DEBUG == 0 && defined(__x86_64__) > // The caller may not create the stack frame for itself at all, > // so we create a reserve stack frame for it (1024b must be enough). > #define HACKY_CALL(f) \ > > > Jakub
