similar to: [LLVMdev] Regular Expression lib support

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 >

On Sun, Aug 23, 2009 at 5:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: > 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

On Sun, Aug 23, 2009 at 3:29 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: >> 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.

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

On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: > 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

On Aug 23, 2009, at 5:50 PM, OvermindDL1 wrote: > On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> > wrote: >> This is too heavy, and we don't need the extra features, and regexec >> is well tested and much more standard. Unless there is an >> overwhelming > > 'regexec' I had never heard of, figured it was a library, turns

On 2009-08-24 07:28, Chris Lattner wrote: > 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

GAH! Why on bloody earth does the LLVM mailing list server not set the response address to the LLVM mailing list server so I actually respond to the server instead of the person above me, that is so different then the other 20+ mailing lists I am subscribed to and I could have sworn the LLVM mailing list was not broken like that before... My message is below: On Sun, Aug 23, 2009 at 4:29 PM,

And I also want to ask again about possible change of regexp library. There are a lot of comments that some changes in FileCheck are useless, because they may be replaced by using some features of regular expressions, but they are not supported by current library. I don't know a lot about modern C++ regexp library, but there are: 1. PCRE(pcre.h) 2. std::regex. It has no necessary features. So

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

Hi Duncan Your suggestion to use '-Bsymbolic' proved to be (almost) the solution. I tried that and it didn't work because I'm using gcc instead of Sun's compilers. It took me a bit of time to discoed that gcc uses '-symbolic' rather than '-Bsymbolic'. Once I figured that out, changing LIBR_LDFLAGS = -shared to LIBR_LDFLAGS = -symbolic -shared in Makeconf

Hi All, I have two small things that I would appreciate some help with: 1. Config/Alloca.h is now dead. Once configure and cmake support is removed, we can zap it. Can someone remove the cmake/autoconf stuff that pokes at Config/Alloca.h? 2. Daniel's regex email. I think the right answer is to just autodetect whether regcomp/regexec etc are available (his #2). Could someone add

A possible regex bug when working with large strings. The following code snippet t5 <- paste( c( "# === TEST", rep(' ', 2452294) ), collapse='') str( sub("^.*TEST", "xyz", t5) ) str( sub("^.*TEST", "xyz", substr(t5,0,200)) ) doesn't behave right; on one machine, the second and third lines print different results [the

On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> wrote: > This is too heavy, and we don't need the extra features, and regexec > is well tested and much more standard. Unless there is an overwhelming 'regexec' I had never heard of, figured it was a library, turns out it is a function call on *nix systems, yea, that is very much not usable in any way

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

A couple of weeks back there was some discussion about documenting the regular expressions as used in R. Several years ago the problem was that this was OS-dependent, and to plug that problem we incorporated regexp code from a version of GNU grep, later updated to grep-2.4.2 in R 1.2.0. I have been looking at documenting what grep(perl=TRUE) does, and we have a similar problem in that the

----- 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

> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > We had a long thread about that a few weeks (months?) ago: the conclusion (as I remember) was roughly a guideline to “always start a new revision to have a proper mailing-list thread starting with context (i.e. patch description)” > (and my dissident minority opinion that it is only

Hello, FileCheck allows us to define match variables and use them on subsequent lines. This is quite useful, but could be even more useful if it was possible to use the variable later on the same line it matched. For example, I would want to write this: ; CHECK: bic [[REG:r[0-9]+]], [[REG]], #3 But I currently can't because [[REG]] will only match a REG variable defined on a _previous_

On Sun, Aug 23, 2009 at 5:04 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Chris Lattner <clattner at apple.com> writes: > >> 1. Config/Alloca.h is now dead.  Once configure and cmake support is >> removed, we can zap it.  Can someone remove the cmake/autoconf stuff >> that pokes at Config/Alloca.h? > > AFAIK, there is nothing specific for