similar to: [LLVMdev] A couple questions

I'm writing a C compiler in OCaml and I've run into a small problem. I wrote the following piece of code to generate a pointer to a string constant, so I could compile C expressions of the form "const char* p = "test\n";" : let strval = const_stringz codecontext v in dump_value strval; dump_value i32_zero; const_gep strval [| i32_zero; i32_zero |] The dump statements

On Feb 14, 2012, at 10:47 PM, Talin wrote: > /// Add a pointer value > template<typename T> > void add(const T *PtrVal) { > addImpl( > reinterpret_cast<const uint32_t *>(&PtrVal), > reinterpret_cast<const uint32_t *>(&PtrVal + 1)); > } > > This violates TBAA rules and looks pretty dangerous to expose as public API.

On Tue, Feb 14, 2012 at 2:44 AM, Chris Lattner <clattner at apple.com> wrote: > On Feb 13, 2012, at 2:00 AM, Talin wrote: >> >> Just out of curiosity, why not MurmurHash3 ? This page seems to >> suggest that #2 has some flaw, and #3 is better all round: >> >> https://sites.google.com/site/murmurhash/ >> > The main reason is because there's no

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

On Tue, Feb 14, 2012 at 2:44 AM, Chris Lattner <clattner at apple.com> wrote: > On Feb 13, 2012, at 2:00 AM, Talin wrote: > > Just out of curiosity, why not MurmurHash3 ? This page seems to >> suggest that #2 has some flaw, and #3 is better all round: >> >> https://sites.google.com/site/murmurhash/ >> >> The main reason is because there's no

On Feb 13, 2012, at 2:00 AM, Talin wrote: > Just out of curiosity, why not MurmurHash3 ? This page seems to > suggest that #2 has some flaw, and #3 is better all round: > > https://sites.google.com/site/murmurhash/ > > The main reason is because there's no incremental version of 3. I think that that is a great reason. > LLVM's needs, on the other hand, are fairly

Thomas Schmitt wrote: > My main point of interest is which block is really loaded as first one > of isolinux.bin. [Program snipped.] > (It could be shorter if i did not insist in big endian words.) Why insisting? Anyway appended is a dumper version. I could put up a binery version if needed. Let me know if so. -- MartinS /*

On May 5, Misha Brukman wrote: > Maybe we can use you for a testimonial... :) Certainly. > > Tail Call Elimination: > > > > I've read over the "Random llvm notes", and see that you guys have > > though about this already. > > > > However, the note dates from last year, so I am wondering if there is > > an implementation in the works.

I was trying to look through the SymbolTable code for LLVM. What does the SymbolTable for a Module contain? Is it just GlobalVariables and Functions? How are program constants and static variables declared within functions handled? When I said program constants, I meant things like strings (e.g., char* foo = "Hello world\n";). Thanks in advance. Sincerely, Brian Brian M.

Hi, recently I took a look at ini to find a bug which made it crash at startup. While fixing the bug I realized I could do some improvements to the option reading code (espacally the action part). So I went on and here we are. This patch should make ini more robust, clean it up and fix also some more crashes I had here. Additionaly, I have a attached a second patch from Maniac which should fix

On Thu, 5 May 2005, Misha Brukman wrote: > On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: >> On May 5, Misha Brukman wrote: >>> To the best of my knowledge, this has not been done and no one has >>> announced their intent to work on it, so if you are interested, >>> you'd be more than welcome to do so. >> >> My C++ knowledge

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

>From the language guide: "The one non-intuitive notation for constants is the optional hexadecimal form of floating point constants. For example, the form 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double 4.5e+15'. The only time hexadecimal floating point constants are required (and the only time that they are generated by the disassembler) is

On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

From: MartinS <ams at ludd.ltu.se> isohdp[fp]v.S which says E or C if EBIOS or CBIOS is used. isohdppv.S also says G or M if a GPT or MBR partition is detected. Signed-off-by: MartinS <ams at ludd.ltu.se> --- Comments? diff --git a/mbr/Makefile b/mbr/Makefile index be2bded..7095396 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -21,7 +21,8 @@ include $(MAKEDIR)/embedded.mk all:

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

LLVM list, I bumped into Alex Friedman in the hall today and by coincidence he mentioned that they were switching to LLVM for their PLT Scheme JIT project. I had evaluated LLVM a few weeks ago for my own purposes, but decided that it was too C/C++ centered and that critical features such as tail call optimization and other stack manipulation features were likely stagnant. So naturally I asked

On Mar 4, 2010, at 4:50 PM, Nyx wrote: > > I'm writing a C compiler in OCaml and I've run into a small problem. I wrote > the following piece of code to generate a pointer to a string constant, so I > could compile C expressions of the form "const char* p = "test\n";" : > > let strval = const_stringz codecontext v in > dump_value strval; >

On Mon, Feb 13, 2012 at 1:22 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > > Here's my latest version of Hashing.h, which I propose to add to > llvm/ADT. > > Comments welcome and encouraged. > > > /// Adapted from MurmurHash2 by Austin Appleby > > Just out of curiosity, why not