search for: tablegenbackends

tl;dr: is anyone opposed to making the interface to a TableGen backend be: void MyBackend(RecordKeeper &, raw_ostream & /* maybe some other args, per backend's needs */); ?? Currently, this is the "interface" for a TableGen backend: struct TableGenBackend { virtual void anchor(); virtual ~TableGenBackend() {} // run - All TableGen backends should implement the run

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib

>> Daniel's comments are also good. > > …success! Looks like I spoke a bit too soon. Everything works as far as the fat binaries are concerned, except that -mmacosx-version-min is set to the host’s OS version, not that of the SDK, causing errors when it tries to link against 10.6’s versions of libraries instead of 10.5’s. This patch appears to solve that; it uses the OS version

Henrik Bach wrote: > Hi LLVM'ers > > When linking tblgen tool I get below error message on MinGW. > > I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. > > However, when rearranging library dbghelp to the end of the g++ > line, tblgen gets linked. It seems that the -L path options are specified before the LLVM libraries (libSystem and libsupport) are linked in.

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f

For those of you who haven't noticed, I'm planning to commit a major change to the Makefile rules tomorrow evening (Tuesday) if there are no complaints about it between now and then. This needs testing on Darwin. I've heard back from Linux on many platforms and even FreeBSD, which is fantastic, but I'm told that lots of LLVMers are running Darwin and I haven't heard a peep

I made my first attempt to build on an x86_64-unknown-linux-gnu system. Is this supposed to work? I get libtools errors (below). The problem seems to be that it finds a 32-bit libltdl rather than the 64-bit libltdl. /home/dag> ls /usr/lib/libltdl.so.3.1.0 /usr/lib/libltdl.so.3.1.0 /home/dag> ls /usr/lib64/libltdl.so.3.1.0 /usr/lib64/libltdl.so.3.1.0 Is this a known problem?

On Mon, Sep 17, 2007 at 12:25:40PM -0700, Chris Lattner wrote: > On Mon, 17 Sep 2007, Emil Mikulic wrote: > >> The 2.1 pre-release (version 1) is available for testing: > >> http://llvm.org/prereleases/2.1/version1/ > > > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > > stale. I tried building LLVM without bison installed and got:

I'm getting an error when trying to build llvm 2.2's tblgen: llvm[2]: Linking Release executable tblgen (without symbols) /usr/bin/ld: Undefined symbols: llvm::MemoryBuffer::getFileOrSTDIN(char const*, unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, long long) llvm::cl::ParseCommandLineOptions(int, char**, char const*) It's

...d AFAIK the only way to really puzzle out the deep details there is to look at the source code of the TableGen backends in utils/TableGen/ and correlating that with the generated .inc files (look in your build dir) and where those .inc files are included inside lib/Target/$ARCH/; see utils/TableGen/TableGenBackends.h for an overview of what's there. There is some rough documentation about them in < http://llvm.org/docs/WritingAnLLVMBackend.html> and < http://llvm.org/docs/CodeGenerator.html>. The actual TableGen "language" is documented fairly poorly but actually has real dedicated...

On Mon, 17 Sep 2007, Emil Mikulic wrote: >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > stale. I tried building LLVM without bison installed and got: Can you try it again without bison with these files:

Jeff & others A couple words on how lib/System works that might help you. 1. The configure script identifies the build host and puts it in the $build variable. We use that to determine the basic kind of platform and put it in a variable named $OS. The value of $OS can be: Linux, FreeBSD, Interix, SunOS, Darwin, etc. 2. The platform name is used to create a link from

Reid, >As for Interix support in general, I'm having a hard time determining >which variant of Unix Interix implements. It seems to be partially Posix >1 and partially Posix 2 based. Do you have any further information >related to the specific standards supported by Interix? I don't want to >incorrectly categorize the Interix support. I've discussed this subject with

When I registered for dev conference, there was a field asking what I was particularly interested in learning. I didn't fill it out then , but it occurs to me now that I'd really enjoy a tutorial on how to develop a new back end. I spent some time recently reviewing existing material (documentation and code) and not making a lot of progress. Indeed, under some time pressure, I'm

Jeff/Vladimir: As with Interix, I've recently added support for FreeBSD into lib/System. Currently, the implementation of FreeBSD just uses the "generic Unix" implementation which probably should work on FreeBSD. If not, I would appreciate it if you could make patches in the FreeBSD directory. If you do, don't forget that you need to remove anything that doesn't work in the

I had llvm 2.9 installed on ununtu. I tried to build clang but got following error. I have llvm 2.9 and clang is latest version ( I don't know, I got from svn). I am wondering is it because of version problem ? Does clang work with 2.9 llvm ? llvm[3]: Compiling ClangASTNodesEmitter.cpp for Debug build In file included from

On Fri, 3 Dec 2004, Reid Spencer wrote: > Could someone please apply this patch to the Win32 support so that > Morten and Jeff can handle the recent changes? I can't do it because > I"m on the road with only email access. I'd be happy to do it. Can someone send me the patch as an attachment off-list? -Chris > > <Tool > >

Could someone please apply this patch to the Win32 support so that Morten and Jeff can handle the recent changes? I can't do it because I"m on the road with only email access. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: Reid Spencer <reid at x10sys.com> > Subject: Updated LLVM Visual Studio project files > Date: Thu,

Current llvm release 2.8 branch at r115409 is broken on x86_64-apple-darwin10. #!/bin/bash -ev export LD=`xcode-select -print-path`/usr/bin/ld xcode-select -print-path ulimit -s `ulimit -s` ulimit -s mv ../clang-2.8 ./tools/clang mkdir ../llvm_objdir cd ../llvm_objdir ../llvm-2.8/configure --prefix=/sw --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw

Hi Jack, I didn't get this error. Could you try again? Is it one of the release candidates in particular that's failing? -bw On Oct 2, 2010, at 8:04 AM, Jack Howarth wrote: > Current llvm release 2.8 branch at r115409 is broken on x86_64-apple-darwin10. > > #!/bin/bash -ev > export LD=`xcode-select -print-path`/usr/bin/ld > xcode-select -print-path > ulimit -s