similar to: [LLVMdev] Oddity in StackerParser.y.

No, $2 is correct. The { } code block before DefinitionList is counted (or more precisely, the empty sequence of terminals preceding it is counted). Ralph Corderoy wrote: >Hi, > > $ g -1 '^Module' StackerParser.y > /* A module is just a DefinitionList */ > Module : { SCI->handle_module_start( ); } > DefinitionList { $$ =

> This is fixed in CVS. You might consider upgrading to LLVM CVS, > especially if you are interested in looking at performance issues: several > important performance related patches have gone in since LLVM 1.2. OK, now i've really upgraded to CVS, but it looks like state of sources is "not compilable" :( indeed: *************************** Linking llc release executable

Hi there! I recently ported Aaron Swartz' html2text.py to PHP and would like to know what you think about it. Any suggestions and bug reports are much appreciated. Check it out: http://milianw.de/projects/html2text/ Note: Michel Fortins PHP Markdown Extended is supported (that is: tables and definitionlist are supported in some way) There are still some bugs but I hope to sort them out

On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > > yesterday I got new SuSE 9.1 DVD, so i am going to enter this > > > river again. Perhaps, this time all will be fine. > > > > Sounds great, please let me know how it goes. > > SuSE 9.1 is running OK. > after 30 minute of compilation i get first errors: > *********************

> > yesterday I got new SuSE 9.1 DVD, so i am going to enter this > > river again. Perhaps, this time all will be fine. > > Sounds great, please let me know how it goes. SuSE 9.1 is running OK. after 30 minute of compilation i get first errors: ********************* make[2]: Leaving directory `/pool/tmp/llvm/runtime/libtrace' make[2]: Entering directory

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards instead of listing all the sources" and then wrote in response to my reply: > On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: > > http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards > > > > is your answer. > > I think their "answer" is

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Reid Spencer wrote: > On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards > instead of listing all the sources" and then wrote in response to my > reply: > >>On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: >> >>>http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards >>> >>>is your

John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution

Hi Reid, > If you're thinking of doing a backend, the LLVM project would probably > benefit more from implementing the virtual backend and its > Interpreter/JIT. This is a long standing project that could > dramatically increase the performance of the ExecutionEngine. The idea > is to write a backend for a virtual machine that closely matches the > semantics of LLVM and then

Hi Chris, > Once you have that, you are hitting another problem. Specifically, > the JIT::getPointerToNamedFunction method in > lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing > symbols. If dlsym returns null, you get the error message. > > The problem here is that .objc_class_name_* are special symbols that > are used by the objc linker support and they

On Fri, 12 May 2006, Ralph Corderoy wrote: >> If you don't *know* that all (e.g.) function pointers to this code are >> dead (which means that execution could come back to the function), you >> should use the ExecutionEngine::recompileAndRelinkFunction(F) method. > > recompileAndRelinkFunction() overwrites the old machine code with a > branch to the new. Is it

On Sun, 6 May 2007, Ralph Corderoy wrote: > Are you aware of buildbot? It's quite widely used and flexible. > http://buildbot.sourceforge.net/ > I'd suggest at least one machine given over to always building whenever > anything changes, and have the other nightly volunteers as now. Using > just nightly volunteers isn't great because breakage is noticed too late >

Hi, I'm slowly getting to grips with what makes up LLVM. I intend to use it in a machine simulator, e.g. processor, clock, RAM, UART, and other devices, where the processor will be one of several. It would take a block of target instructions, e.g. ARM, and produce LLVM to simulate those on the target machine state, and then JIT them to host instructions and then execute. The peripheral

Hi Chris, > The LLVM X86 backend started out emitting intel mode for use with GAS > and it's "intel syntax mode" (which does use registers with %'s). > Unfortunately GAS has (or commonly available versions have) a number > of bugs in intel syntax mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax. Ah, OK.

Chris Lattner wrote: > On Mon, 1 May 2006, Ralph Corderoy wrote: > >> >> NASM might be the nicer target since it's GNU LGPL and runs on multiple >> OS. Its home page is broken at the moment, but the manual pages work. >> >> http://nasm.sourceforge.net/doc/html/nasmdoc0.html > > That's fine with me. The instructions are in true intel mode now,