search for: stepanov

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 29 July 2014 15:02, Evgeniy Step...

Yup, using SIGHUP works. On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is > not guaranteed to be delivered (to the same process!) before kill() > returns? Could you check if that's what happens by adding a sleep() > somewhere? > >...

On 29 July 2014 15:02, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I > don't see how they are different. So, AFAIK, they should be identical. But I put some printfs and sleeps around and it wasn't a synchronization issue. My man page says th...

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores...

..._signals.cc.tmp", expecting it to fail. Also, the FileCheck expects to find warnings on the output, for which there is none Maybe I'm missing some CMake flag or library, and that's why the signal functionality is not working on my box? cheers, --renato On 25 July 2014 09:39, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Hi, > > is it still an issue? > Just by looking at the code, I don't see why it could fail. Do you > need any help debugging it? > > On Wed, Jul 23, 2014 at 1:15 AM, Renato Golin <renato.golin at linaro.org> wrote: >&gt...

...0000e23 o: 40000e23 o: 40000e23 > $21 = void > (gdb) p __msan_print_shadow(&ptr,8) > ff ff ff ff ff ff ff ff > o: 40000e23 o: 80007614 > $22 = void > > Notice the origin of the lower bits is off. Any idea as to why? > > > On Mon, Feb 3, 2014 at 2:52 AM, Evgeniy Stepanov < > eugeni.stepanov at gmail.com> wrote: > >> The code for ccall looks right. Sounds like you have a very small >> range of instructions where an uninitialized value appear. You could >> try debugging at asm level. Shadow for b should be passed at offset 0 >> in...

> -----Original Message----- > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com] > Sent: Wednesday, December 07, 2016 4:51 PM > To: Kostya Serebryany > Cc: Robinson, Paul; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Debug Locations for Optimized Code > > In fact, we are already using "parallel" debug in...

On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header must define aligned_alloc(). Really? >> >> in...

..._origin_tls to i64), i64 16) to i32*), align 4, !dbg !7 > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*), align > 8, !dbg !7 > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7, !julia_type > !9 > > > > On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> > wrote: >> >> How is ccall() implemented? If it manually sets up a stack frame, then >> it also needs to store argument shadow values in paramtls. >> >> I don't think there is an overflow, unless you have a _lot_ of >>...

Evgenii Stepanov <eugeni.stepanov at gmail.com> writes: > See https://reviews.llvm.org/D51364 - a very similar bug was > introduced by a compiler-rt change and then fixed by a revert. Ok, so what do we do about this? D50940 seems to have introduced the problem but it was reverted. The "tentativ...

Hi, we plan to remove -fsanitize-address-zero-base-shadow command line flag from clang, and disable zero-base shadow support on all platforms where it is not the default behavior. - It is completely unused, as far as we know. And completely undocumented, too. - It is ABI-incompatible with non-zero-base shadow, which means all objects in a process must be built with the same setting. Failing to

...that the the C library should guarantee that from the way >>> the relocations are implemented as long as both native and JITed code are on >>> the same thread (but I will verify this and report back). >>> >>> >>> On Tue, Jan 28, 2014 at 2:41 AM, Evgeniy Stepanov >>> <eugeni.stepanov at gmail.com> wrote: >>>> >>>> I assume there are transitions between JITted code and native helper >>>> functions. How are you handling them? Are native functions >>>> MSan-instrumented? >>>> MSan is pa...

...M Subject: buildbot failure in LLVM on llvm-mips-linux To: Ahmed Bougacha <ahmed.bougacha at gmail.com>, Chad Rosier < mcrosier at codeaurora.org>, David Blaikie <dblaikie at gmail.com>, Davide Italiano <davide at freebsd.org>, Dehao Chen <dehao at google.com>, Evgeniy Stepanov <eugeni.stepanov at gmail.com>, Hal Finkel <hfinkel at anl.gov>, Kostya Serebryany <kcc at google.com>, Michael Zolotukhin <mzolotukhin at apple.com>, Reid Kleckner <rnk at google.com>, Sanjay Patel <spatel at rotateright.com> Cc: gkistanova at gmail.com The Bu...

.... One of the shared libraries I load calls strtol and msan fails to intercept it. Why would this be? The library seems to be otherwise implemented. One of the potential culprits I saw is that strtol is marked as strong in libc. Is there any workaround? Keno On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Hi everyone, > > > > I ran into a false positive with memory sanitizer due to it not > intercepting > > dlinfo. I tried t...

Hi, In the quest for better test cases for my MP, I thought of trying the Stepanov Abstraction Penalty benchmark. But apparently llvm-g++ is not ready for such terrible things. Let me know if you want me to send the source code (it is widely available). gaeke|csil-suna37|~/cs/426/MP1/step|[1177]% /usr/dcs/projects/cs426/Software/gcc_install/bin/g++ stepanov.cpp -o stepanov In fi...

On 27 November 2013 08:43, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > Also note that tail merging of calls happens in CodeGen, not in > SimplifyCFG. > Hi Evgenly, What we need is the general information that we want to avoid too much code motion, from choosing the passes, to choosing steps on the passes, to low...

...; >> >> >> >> > Yes, so "ninja install" is optional. >> >> But the 'install' depends on the 'all' target. >> >> -Greg >> >> >> >> >> >> >> On Fri, Mar 28, 2014 at 12:39 AM, Evgeniy Stepanov >> <eugeni.stepanov at gmail.com> wrote: >> > On Thu, Mar 27, 2014 at 10:18 PM, Greg Fitzgerald <garious at gmail.com> >> > wrote: >> >>> Alexey's approach with CMake sub-projects. >> >> >> >> I prefer that direction as...

...umented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are implemented as long as both native and JITed code are on > the same thread (but I will verify this and report back). > > > On Tue, Jan 28, 2014 at 2:41 AM, Evgeniy Stepanov < > eugeni.stepanov at gmail.com> wrote: > >> I assume there are transitions between JITted code and native helper >> functions. How are you handling them? Are native functions >> MSan-instrumented? >> MSan is passing shadow across function calls in TLS slots. Do...

On 1 December 2013 10:44, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Could we move this setting to function attributes? I think this is a good idea. > This would let us support __attribute__((optimize())) in the future, > which is currently ignored. I'm adding #pragma vectorize enable which does more or...

...ld need to do the same in the llvm repo. The alternative is to run a separate cross-compiled build for each architecture. :-/ > Yes, so "ninja install" is optional. But the 'install' depends on the 'all' target. -Greg On Fri, Mar 28, 2014 at 12:39 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > On Thu, Mar 27, 2014 at 10:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>> Alexey's approach with CMake sub-projects. >> >> I prefer that direction as well, but what I've proposed is a solution >> tha...