similar to: [LLVMdev] Test Message

Dear All, This is simply a test message to see if the llvmdev list is operational. Please ignore. -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign

Dear All, I'm getting the following error on Mac OS X when compiling C++ code in the LLVM test suite: g++ Output/minisat.llc.s -o Output/minisat.llc -lm -m64 -fomit-frame-pointer -mdynamic-no-pic -lstdc++ -lm Output/minisat.llc.s:5:Unknown pseudo-op: .cfi_startproc Output/minisat.llc.s:8:Unknown pseudo-op: .cfi_def_cfa_offset Output/minisat.llc.s:8:Rest of line ignored. 1st junk

Dear LLVM'ers, Today I moved some items around in the test suite. Specifically, I moved some regression tests into llvm/test/Programs/SingleSource/Regression. For those of you updating from CVS, you will need to re-run the configure script in order to populate your object tree with the new Makefiles that run these tests. We had a few glitches with this earlier today, but hopefully

On 10/23/12 7:19 PM, Craig Topper wrote: > What function provides the encoding length? X86 in particular is so > difficult to encode that only the old style JIT and the MC Code > Emitter could possibly know how many bytes something takes. The getSize() method of MCInstrDesc which can be fetched from a MachineInstr using the getDesc() method:

Dear yueqiang, After some investigations, Chris and I think we know why these warnings are occuring. In RedHat Linux 8, the size of struct __locale_struct changed in /usr/include/xlocale.h. Our LLVM GCC system (including libstdc++.a) was compiled on a RedHat 7.3 system. Many of the type conflicts that you are seeing occur because the C++ library thinks that some of the types based upon

Hi, [resurrecting an old mail thread about AddressSanitizer false positive caused by load widening] Once the Attribute::AddressSafety is set by clang (a separate patch), fixing this bug may look as simple as this: --- lib/Analysis/MemoryDependenceAnalysis.cpp (revision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@

Alexander Friedman wrote: > On May 17, John Criswell wrote: > >>Dear All, >> >>I've finished building binaries for the GCC frontends and am now testing >> the 1.5 release branch on i386/Linux, Sparc/Solaris, and PowerPC/MacOS X. >> >>I'm looking for volunteers to test LLVM 1.5 on platforms that we don't >>have in house. I'm

On 12/2/11 4:27 PM, Eli Friedman wrote: > On Fri, Dec 2, 2011 at 2:23 PM, John Criswell<criswell at illinois.edu> wrote: >> On 12/2/11 3:24 PM, Eli Friedman wrote: >>> On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> >>> wrote: >>>> Dear All, >>>> >>>> Is there an optimization in the x86 back-end

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding

On 12/2/11 3:24 PM, Eli Friedman wrote: > On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> wrote: >> Dear All, >> >> Is there an optimization in the x86 back-end that could cause two >> alloca's to use overlapping memory? > It's theoretically possible, but IIRC there isn't any such > optimization implemented at the moment.

Dear LLVM Developers, The LLVM website, CVS repository, and SAFECode website should now be back online. Should you encounter any problems with the LLVM services, please send email to llvmdev at cs.uiuc.edu so that we may fix it. Regards, John T. Criswell ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu

Hi John, Chandler, I completely agree. Cheers, Renato On 25 Sep 2014 17:39, "John Criswell" <jtcriswel at gmail.com> wrote: > Dear All, > > Two quick comments: > > 1) Don't suggest that titles be 70 characters but that 80 is okay. Just > say they should be at 70 characters and leave it at that. > > 2) +1 for Chandler's comment that what is really

Hi, It looks like the CVS server is still not available. When I try to update with cvs, I get: cvs [update aborted]: connect to llvm-cvs.cs.uiuc.edu(128.174.245.58):2401 failed: Connection refused I know the server was down earlier this week but according to the message below, its supposted to be restored by now. Could someone please help? Thanks, Reid. On Wed, 2004-01-07 at 14:30, John T.

Hi John, > The -internalize pass changes globals to have internal linkage. Does this > not suffice for your needs? To my understanding, it does not. The -internalize pass performs: I->setLinkage(GlobalValue::InternalLinkage); which means it only changes the linkage mode, while global variables remain in place. And we need to *replace* globals with local variables in main and

Dear All, Do people think that they are ready to create the LLVM 1.6 release branch? I believe all the development is pretty much done. Is all the documentation in the LLVM source tree updated and ready? I'm not able to make a full doc review like I've been able to do in previous releases, so I need volunteers to work on the docs if they're not done yet. -- John T. -- John

What function provides the encoding length? X86 in particular is so difficult to encode that only the old style JIT and the MC Code Emitter could possibly know how many bytes something takes. On Tue, Oct 23, 2012 at 11:58 AM, John Criswell <criswell at illinois.edu>wrote: > Dear All, > > I'm enhancing a MachineFunctionPass that enforces control-flow integrity. > One of the

On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu>wrote: > Dear All, > > I think adding metadata and expecting transforms to repect it is a bad > idea. It is just too easy for someone who does not know about the metadata > to add a transform that ignores it. > > As for SAFECode, I think we have one of several options for handling >

Dear All, Our main server is back up, and all LLVM services (CVS, website, etc) should be up and available for use. If you notice that something is wrong, please send an email to llvmdev at cs.uiuc.edu. Thanks! -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer

ymxia at nudt.edu.cn wrote: > Hi, > > I want to check some properties of linux kernel with llvm, but I don't know how to compile a > > linux kernel to an llvm's .bc file. I have let llvm's gcc front-end ignore inline assembly by > > modifying cfrontend/src/gcc/llvm-expand.c, and replace CC/as/ar in the Makefile of the kernel > > with

On 8/24/11 1:51 PM, Eli Friedman wrote: > On Wed, Aug 24, 2011 at 11:41 AM, John Criswell<criswell at illinois.edu> wrote: >> Dear All, >> >> I currently have one of my transforms creating the following store >> instruction: >> >> store [65536 x i8] zeroinitializer, [65536 x i8]* %buf.i, align 16 >> >> ... which causes the SelectionDAG code