similar to: [LLVMdev] linkage errors while buliding tblgen

Hi, Trying to build llvm on irix mips with gcc 3.4.6 and receiving the following types of errors ld32: ERROR 33 : Unresolved text symbol "std::basic_string<char, std::char_traits<char>, std: :allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator <char> > const&)" -- 1st referenced by

Hi Frederick, > Trying to build llvm on irix mips with gcc 3.4.6 and receiving the following types of errors > > ld32: ERROR 33 : Unresolved text symbol "std::basic_string<char, std::char_traits<char>, std: > :allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator > <char> > const&)" -- 1st

Hi, I see that llvm has a Mips target already written up. Does anyone know how current this is? Does anyone maintain this and/or have any details about this target in terms of functionality regarding JIT etc.? Also I was trying to configure it with CC and CXX set to the mips 7.4.4 compilers but I get the error gcc|icc not configured. I am a real newb and don't really get how the gcc front

Hi Jack, On Jan 25, 2012, at 6:45 PM, "Carter, Jack" <jcarter at mips.com> wrote: > I'm trying to generate MipsGenAsmMatcher.inc for MipsAsmParser.cpp. > > What added restrictions for the .td file contents are there for tblgen -gen-asm-matcher? > Lots, as you're finding, almost all of them completely undocumented. :( > For the Mips platform we create

I'm trying to generate MipsGenAsmMatcher.inc for MipsAsmParser.cpp. What added restrictions for the .td file contents are there for tblgen -gen-asm-matcher? For the Mips platform we create the following .inc files through tblgen. tablegen(LLVM MipsGenRegisterInfo.inc -gen-register-info) tablegen(LLVM MipsGenInstrInfo.inc -gen-instr-info) tablegen(LLVM MipsGenCodeEmitter.inc -gen-emitter)

Hey Chris, Ok, so I'm working on creating this trivial patch, for starters, but I'm trying to identify a controlled unit test for tblgen. So all of the following test tblgen to various extents: 1) make 2) make unittests 3) make // with clang and 4) make check // which I'm avoiding Since I'm just starting to understand tblgen, I'm not comfortable with any of these

Hi, everyone. Does anyone faced with the MSVC Debug build issues of clang-tblgen and llvm-tblgen? I'm using Windows10 Pro. MSVC and GCC. Here is my cmake setup: cmake -GNinja ../llvm -DLLVM_ENABLE_PROJECTS=clang -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug When building debug with GCC, cmd shows next: D:\llvm-project\buildn2\bin>clang-tblgen.exe --version LLVM

On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation > accesses the global Records instance instead of just referencing itself? > > As far as I can tell from the usage: > > 1) Records has the linkage as extern RecordKeeper Records in Record.h > 2) Is instantiated as a global in TableGen >

Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...) dependency on the global RecordKeeper Records instance. The real work will be removing this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would be implemented as some sort of context structure/class holding a RecordKeeper instance passed to TGParser which in turn

On the trunk version of LLVM I am getting the following build error on Snow Leopard (v10.6.2): llvm[3]: Building X86.td DAG instruction selector implementation with tblgen Assertion failed: (LHS->ID != RHS->ID), function operator(), file /Users/peckw/Projects/llvm/llvm-pristine/utils/TableGen/DAGISelEmitter.cpp, line 183. ... <cut - see full_stack_trace.txt> 0. Program arguments:

On Wed, Feb 06, 2013 at 11:47:31PM +0100, Dmitry Mikushin wrote: > Dear all, > > I need your help to understand weird llvm-tblgen behavior. Please take your > favourite version of llvm-tblgen and use it in the root directory of the > archive attached in both bug reports: > > http://llvm.org/bugs/show_bug.cgi?id=15188 > http://llvm.org/bugs/show_bug.cgi?id=15189 $

Hi, I am trying to build a new backend target. First I wanted to start with just one intrinsic function. So I followed (I think I did) the guidelines about doing. For some reason I am getting this error message from the tblgen: "In SU_routeInstr: Type inference contradiction found in node imm!" Here is my def Imm8Arg: Operand<i8> { let

I want to generate Haskell bindings to LLVM intrinsics. In a first attempt I wrote a little parser that reads IntrinsicsX86.td and outputs a Haskell module. E.g. the definition def int_x86_avx_max_ps_256 : GCCBuiltin<"__builtin_ia32_maxps256">, Intrinsic<[llvm_v8f32_ty], [llvm_v8f32_ty, llvm_v8f32_ty], [IntrNoMem]>; is turned into

https://bugzilla.mindrot.org/show_bug.cgi?id=1607 Summary: compile errors buliding OpenSSH for older Red Hat Product: Portable OpenSSH Version: 5.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: unassigned-bugs at mindrot.org

Dear all, I need your help to understand weird llvm-tblgen behavior. Please take your favourite version of llvm-tblgen and use it in the root directory of the archive attached in both bug reports: http://llvm.org/bugs/show_bug.cgi?id=15188 http://llvm.org/bugs/show_bug.cgi?id=15189 ==== 1) First test case: crashing ==== $ ./llvm-tblgen -gen-tgt-intrinsic NVPTX1.td assert(iid <=

Hi all, when trying to build LLVM+Clang (r180247) on a BlueGene/Q, I get the following error message (multiple times): llvm[3]: Building PPC.td code emitter with tblgen llvm-tblgen: Unknown command line argument '-gen-emitter'. Try: '/homea/jjsc13/jjsc1301/.pool/.build/llvm_r180241/Release+Asserts/bin/llvm-tblgen -help' llvm-tblgen: Did you mean '-mc-emitter'? Has

On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan <ivanllopard at gmail.com> wrote: > Hi all, > > I am writing a back-end for a processor that has complex type registers. > It has two functional units to perform complex multiplications. >  From clang, I emulate a complex multiplication using vectors and, at > the IR, I got this tblgen-friendly pattern (real component) : >

Allow me to rephrase my question: How much agony and gnashing of teeth will I cause if I commit this patch to tblgen (fully tested and changes to DAGISelEmitter.cpp also committed)? -scooter On Feb 8, 2008, at 6:43 PM, Scott Michel wrote: > Question: How hard should tblgen try to fit constants into a > particular > type? > > My case is an xor with i8 immediate where

On Dec 9, 2011, at 4:12 PM, Ivan Llopard wrote: > Hi Eli, > Thanks for your response. Please see my responses below. > > On 10/12/2011 00:28, Eli Friedman wrote: >> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >>> Hi all, >>> >>> I am writing a back-end for a processor that has complex type registers.

On 10/12/2011 01:32, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Eli, >> Thanks for your response. Please see my responses below. >> >> >> On 10/12/2011 00:28, Eli Friedman wrote: >>> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>> wrote: