similar to: [LLVMdev] help with llvm make system

Hi, I'm working on a compiler for a small toy language and I'm using the llvm sample project layout, i.e. the llvm make system. I've got one library (lomo-core) which contains my parser and all that stuff and one tool (lomoc) which is my compiler executable. The tool declares the library as dependency using: USEDLIBS = lomo-core Now that I've started to add IR generation I

Hi, thank you for your response. Óscar Fuentes schrieb: > It would be useful to see the first error messages and the compile > command (do make VERBOSE=1 in case it is hidden the first few errors are: f:/dev/projects/llvm-2.5/include/llvm/Support/Annotation.h:42: error: expected unqualified-id before numeric constant f:/dev/projects/llvm-2.5/include/llvm/Support/Annotation.h: In

Stefan Oestreicher <stefan.oestreicher at deluxe-design.at> writes: [snip] > Unfortunately no matter what I do to the makefile of the compiler tool > it won't compile. I always get errors in llvm/Support/Annotation.h that > look like some type declarations are missing. Unfortunately my > experience building C/C++ programs, especially with autoconf etc., is > very

That sounds like a problem. Just so I understand, do you mean there isn't the run-time support etc. to write back ends for the C++ language, or that the compiler IR is also somehow insufficient to write a code generator? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Jul 11, 2009, at 3:00 PM, Granville Barnett

On Mon, Aug 31, 2009 at 6:23 PM, Samuel Crow<samuraileumas at yahoo.com> wrote: > If you're wondering why we're doing an interpreted PEG parser generator rather than Boost Spirit 2.x, it's because we need it to be easier to debug the parser.  Once the parser is debugged it can be fed into a compiled parser generator and "frozen" into stand-alone parser code. You do

Whoops, sending it to to llvm list as well, freaking takes another ~70 seconds to do a reply to all instead of a reply to, headers still not following standards of every other list I have ever been on... On Wed, Sep 23, 2009 at 6:34 AM, Stefan Oestreicher <stefan.oestreicher at deluxe-design.at> wrote: > Hi, >> I have no >> idea why it works now, there is no difference. >

When you create a parser via ANTLR you specify the output language of the resulting recursive descent parser, at the moment there exists no C++ output template to my knowledge, thus you would have to generate the parser as C code for which a template exists. The runtime support should be there, at least partially but it won't use things like exceptions, nor will it have a very modular design

----- Original Message ---- > From: Eli Friedman <eli.friedman at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, August 31, 2009 3:49:01 PM > Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT > > On Mon, Aug 31, 2009 at 12:17 PM, Samuel

Hello OvermindDL1, We are implementing an extensible language. That's one where you can add commands and constructs to the language without having to recompile the parser. We want compilation of the parser in order to "freeze" it but only as an option. One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template

We would like to have access to some kind of regular expression library inside LLVM. For example, we need this to extend the FileCheck test case checking tool to support regular expressions. There are three obvious options: 1. Roll our own library. Multiple unnamed individuals may even already have implementations lying around! :) 2. Use POSIX regcomp facilities. This implies importing some

On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: >> 2. Use POSIX regcomp facilities. This implies importing some >> implementation of this interface, e.g., Windows. On Linux, BSD, etc. >> we would try to use the platform version if available (and non- >> buggy). > > Don't do it. > They are ridiculous slow, and posix made some really dumb choices in >

OvermindDL1 wrote: > Again, why not Spirit2.1, works just fine on C++98, and it is fast, > and it is split up into the smallest bits so you only include what you > use, and the assembly it compiles into is *very* tiny, far far less > then any regex library could possibly be. > Spirit is not an option for one simple reason: FileCheck needs to parse regexes from its instruction

On Sun, Aug 23, 2009 at 10:20 PM, Chris Lattner<clattner at apple.com> wrote: > On Aug 23, 2009, at 9:11 PM, OvermindDL1 wrote: >>> >>> Again, forget boost regex. :) >> >> What about std::regex? > > No, we have to build with c++'98 compilers. I think you're missing the > point here. We care about code size in llvm, and the best code size

We are looking for an open source C++ parser other than g++ if possible. Clang would be great but its C++ support is still some way away and we need something that works or nearly works now. Does anyone have any experience with ANTLR for parsing C++ and for extending their C++ parser? Any other feedback on ANTLR in general would be welcome too. Thanks, --Vikram Associate Professor,

Hi, I've not got any experience using ANTLR to parse C++, however, you will find that there only exists a C code generator for ANTLR and NOT a C++ one. Over the years numerous people have requested a C++ code generation template but alas there is still only a C one. Just a heads up. Granville 2009/7/11 Vikram S. Adve <vadve at cs.uiuc.edu> > We are looking for an open source C++

Has anyone written a grammar for LLVM for ANTLR. I mean an ANTLR grammar that parses LLVM instructions. Is an LLVM grammar available for any other parsing tool? Surinder

Hi, I'm playing around with llvm and the Kaleidoscope tutorial and first of all I have to say I'm really impressed. LLVM rocks! Unfortunately I've now run into a linker error while trying to optimize the IR or turn it to bitcode and likely due to my very limited experience with c++ I just can't figure out how to resolve it. The linker complains that the llvm::WriteBitcodeToFile

On Jul 11, 2009, at 12:40 PM, Vikram S. Adve wrote: > We are looking for an open source C++ parser other than g++ if > possible. Clang would be great but its C++ support is still some > way away and we need something that works or nearly works now. Does > anyone have any experience with ANTLR for parsing C++ and for > extending their C++ parser? Any other feedback on

For a LL(1) parser, it might be a little bit difficult to parse complex grammar like C++, but it might work. ANTLR worked great when other codes were written in Java, but it was a little bit painful when using other languages like python. I worked on it two years ago. I guess they might have some improvement now. Haohui On 07/11/2009 02:40 PM, Vikram S. Adve wrote: > We are looking for an

Hello LLVM Devs, I thought I'd weigh in on some of these non-backtracking linear time RegEx algorithms. If they're anything like the PackRat parsing algorithms they take at least 4x the amount of memory in terms of storage as the string length itself by not backtracking. That should be fine for small RegExes but it wouldn't do so well for more elaborate and long expressions. If