similar to: [LLVMdev] Valgrind memcheck errors in llvm

Hi, I compressed a folder with the following script: ... for i in *.*.*; do file $i | grep bzip2 >/dev/null 2>&1 if [ $? -ne 0 ]; then echo "Compress: $i" cat "$i" | bzip2 -9 > ../tmp/$i if [ $? -eq 0 ]; then mv ../tmp/$i $i fi else

Hi, We are having an issue with the loop vectorizer and noalias pointers, as it is generating `vector.memcheck` while we can guarantee that the pointers will not overlap. It seems that in `LoopVectorize.cpp` the function `emitMemRuntimeChecks` is called but there are no checks to disable this behavior (like "strong noalias") We are actually using a technique similar to the

Hi the list, One of my package has an (other) error detected by memtest that I do not manage to understand. Here is the message that I get from Memtest --- 8< ---------------- > try(choice(cld1)) Error in switch(EXPR = choix, Up = { : EXPR must be a length 1 vector --- 8< ---------------- The choice function does call the choiceChangeParam function, which is: --- 8<

I'm building a simple R extension around a CUDA-enabled dynamic library, and I want to run the whole package with cuda-memcheck for debugging purposes. I can run it just fine with Valgrind: $ R --no-save -d valgrind < test.R However, if I try the same thing with cuda-memcheck, $ R --no-save -d cuda-memcheck < test.R I get: *** Further command line arguments ('--no-save ')

Hi the list, One of my package has a memory issue that I do not manage to understand. The Memtest notes is here: <http://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/kml-Ex.Rout> Here is the message that I get from Memtest --- 8< ---------------- ~ Fast KmL ~ ==27283== Invalid read of size 4 ==27283== at 0x10C5DF28: kml1 (kml.c:183) ... ==27283== by 0x10C5DE4F: kml1 (kml.c:151)

It seems that at some point in the not-so-distant-past that the loop vectorizer gained the ability to vectorize loops without explicit `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's awesome, there seems to be a regression in that `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias analysis, and therefore a `vector.memcheck` basic block is

I'm having a problem with MCJIT (in LLVM 3.3 and 3.4), in which it's not resolving symbol mangling in a precompiled bitcode in the same way as old JIT. It's possible that it's just my misunderstanding. Maybe somebody can spot my problem, or identify it as an MCJIT bug. Here's my situation, in a nutshell: * I am assembling IR and JITing in my app. The IR may potentially make

Hi all, I'm trying to reduce the startup time for my JIT, but I'm running into the problem that the majority of the time is spent loading the bitcode for my standard library, and I suspect it's due to debug info. My stdlib is currently about 2kloc in a number of C++ files; I compile them with clang -g -emit-llvm, then link them together with llvm-link, call opt -O3 on it, and arrive

This is sounding rather like getLazyBitcodeModule is simply incompatible with MCJIT. Can anybody confirm that this is definitely the case? Is it by design, or by omission, or bug? Re your option #1 and #2 -- sorry for the newbie questions, but can you point me to docs or code examples for how the linking or object caching should be achieved? If I do either of these rather than seeding my

That was likely type information and should mostly be fixed up. It's still not lazily loaded, but is going to be ridiculously smaller now. -eric On Fri Jan 10 2014 at 12:11:52 AM, Sean Silva <chisophugis at gmail.com> wrote: > This Summer I was working on LTO and Rafael mentioned to me that debug > info is not lazy loaded, which was the cause for the insane resource usage > I

Adrian may have handled this recently? On Jan 13, 2014 3:34 PM, "Manman Ren" <manman.ren at gmail.com> wrote: > I briefly looked at the bit code files and some types are not uniqued, > here is one example: > !3903 = metadata !{i32 786454, metadata !3904, null, metadata !"int64_t", > i32 198, i64 0, i64 0, i64 0, i32 0, metadata !2258} ; [ DW_TAG_typedef ]

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM,

Hi all! I have several VMs, all in virtualbox 6.0.14 and all the VBOX add-ons are up to date. I don't use them daily, last used any of them probably 4-6 weeks ago, pretty sure it was already running 6.0.14 by that time. they were all fine when last used. Two of them are C7, one is a clone of the other, and the other is C8. each seems to have different symptoms. the C7 clone claims there

Hi, Our Samba Servers are getting slower and slower. Even opening the context menu on some files take 5 seconds. My log file is filled up with messages like: nsaction 909 of length 1454 [2005/10/31 12:58:04, 3] smbd/process.c:switch_message(886) switch message SMBsesssetupX (pid 24227) conn 0x0 [2005/10/31 12:58:04, 3] smbd/sec_ctx.c:set_sec_ctx(288) setting sec ctx (0, 0) -

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

all of: ---- // cout << "lsr: " << lsr << "\n"; llvm::MemoryBuffer* mbjit = llvm::MemoryBuffer::getMemBufferCopy (sr); ------ string lsr = sr.str(); // cout << "lsr: " << lsr << "\n";

This segfault occuring only under valgrind, in shell way, and in gdb way i have Invalid bitcode signature simple_scev_dynamic_array: /home/willy/apollo/llvm/include/llvm/Support/ErrorOr.h:258: storage_type *llvm::ErrorOr<llvm::Module *>::getStorage() [T = llvm::Module *]: Assertion `!HasError && "Cannot get value when an error exists!"' failed. Command terminated by

Hello Willy, Here is the dump from one of my bitcode files: 0000000 42 43 c0 de 21 0c 00 00 25 05 00 00 0b 82 20 00 As expected, 0x42 (= B), 0x43 (= C), xc0 and 0xde are in correct order. In your case, the first byte is read as 37 (= 0x25). I wonder why? When you check the bytes yourself, you get expected results. When the same bytes are read from Stream object, you get a different result (maybe

Hello, have somebody get the Tomcat 6 native lib to build? When I try to run ./configure --with-arp=/usr/bin/apr-1-config under /opt/apache-tomcat-6.0.14/bin/tomcat-native-1.1.10-src/jni/native I only get the error: configure: error: cannot find install-sh or install.sh in build ./build Any ideas how to to resolve this? Thanks

Hi everyone, In debugging an LLVM based system with a runtime module loaded from bitcode, I ran into a strange error when trying to use getLazyBitcodeModule instead of just ParseBitcodeFile (when loading lazily I get an "Invalid CALL" during bitcode deserialization). I can't decide if this is a "bug" or just a "you shouldn't use Module/Inliner like this".