similar to: [LLVMdev] Problem building llvm after r109996 (Add InitializeNativeTargetAsmPrinter())

Hi Jean-Daniel, My fault, I'm sure, but I don't see the problem yet. Is it possible your version of llvm/Config/AsmPrinters.def has X86 listed twice? - Daniel On Mon, Aug 2, 2010 at 12:43 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After I try making a clean build and got the following error: > > llvm[3]: Compiling EDDisassembler.cpp for

The following configure/make is failing on the top of tree llvm/clang sources: ./configure --enable-optimized --disable-assertions --enable-targets=x86,x86_64,arm --build=x86_64-apple-darwin10 ./make clang-only llvm[2]: Compiling Tool.cpp for Release build In file included from /Volumes/work/gclayton/Documents/src/llvm/include/llvm/Target/TargetSelect.h:38, from

Hi, I just checked out llvm from svn and attempted to build the systemz + cpp targets. I am getting the following error: EDDisassembler.cpp:42:49: error: ../../lib/Target/X86/X86GenEDInfo.inc: No such file or directory Is that file which is generated as part of the build process? If so, I assume EDDisassembler shouldn't be compiled for a systemz build. Neale -------------- next part

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > thanks for your comments. I'll respond to them individually. I've > attached a new revision of the patch that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I

I was away doing other things for a while, but I have an API patch separated out, which (in addition to being much smaller than past megapatches) corrects two issues Chris identified in his most recent set of patches: - First, it makes the API a good deal simpler. Now, you can instantiate a single MCDisassembler and, each time you want an instruction disassembled, you can simply pass

*1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build directory, recursively, and all the output is what I pasted in last email (just the same to the that in source directory). Maybe the configure failed to do it. My command list for building the test suit is as followings:* *(1) cd ~/SRC_DIR/llvm/projects* *(2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk

Bill, thanks for your comments. I'll respond to them individually. I've attached a new revision of the patch that addresses them. Patch built and tested against SVN 79487, with the additional attached fix that fixes an Intel table bug. Sean On 2009/08/18, at 0:57, Bill Wendling wrote: > 0. Watch out for tabs! Fixed. Thanks. > 1. Includes like this "#include

Current llvm svn at r136461 is failing to bootstrap under darwin11 with... cd /sw/src/fink.build/llvm30-3.0-0/llvm-3.0/build/tools/edis && /sw/bin/cmake -E cmake_link_script CMakeFiles/EnhancedDisassembly.dir/link.txt --verbose=1 /sw/var/lib/fink/path-prefix-clang/c++ -fPIC -fno-rtti -O3 -DNDEBUG -shared -L/sw/lib -o ../../lib/libEnhancedDisassembly.dylib -install_name

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

*I am sorry for making you confused when I presented my problem.* *1. My steps for the test suit building:* (1) cd /home/qali/Src; * // This is my source directory for all application programs* (2) tar xzf llvm-2.8.tgz; * // now, the top directory of source tree is /home/qali/llvm-2.8* (3) cd llvm-2.8/projects (4) svn co http://llvm.org/svn/llvm-project/test-suite/trunk

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

Hi, I am trying to add a small new backend for LLVM. For assembly printing, I have derived a class from AsmTarget, struct LLVM_LIBRARY_VISIBILITY Asd_ARMAsmPrinter : public AsmPrinter After creating all the bits and pieces, I was trying to use this to print the assembly for a sample program. Though I was getting weird errors. I tried looking for the problem and found that the my target