search for: ochtman

On Tue, Feb 17, 2015 at 8:56 AM, Antoine Pitrou <antoine at python.org> wrote: > > Hi, > > Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes: > > > > As far as I understand, this change is wanted because the LLVM > > infrastructure derives no value from knowing the types, and there's a > > cost in terms of code spent to support all of it. I've been creating a &...

Hi there, Sorry, I don't have the thread history to reply to since I normally read llvmdev through the archives, but wanted to give my .02 of feedback anyway. As far as I understand, this change is wanted because the LLVM infrastructure derives no value from knowing the types, and there's a cost in terms of code spent to support all of it. I've been creating a frontend that mostly

On Wed, Jan 16, 2013 at 5:18 PM, Eli Bendersky <eliben at google.com> wrote: > I think it makes sense to create a bug report. Looking at the code of > LLParser::ParseGetElementPtr, the error handling appears to be very > simplistic, so I don't think there's any fundamental reason for not > doing a better job there. Filed http://llvm.org/bugs/show_bug.cgi?id=14965,

... and that's kind of annoying when I'm trying to debug something. Also, it doesn't seem like openssh.org lists the IRC channel (even though it's referenced) anywhere. Cheers, Dirkjan

On Thu, May 24, 2012 at 12:53 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > One project I'd like to complete pretty soon is to go through the build > instructions, for mingw32, and see if I can't somehow create a mingw64 > build.  I believe the 32-bit platform is dying by the hour so I'm rather > eager to have a mingw64 version of LLVM/Clang.  Also, I'd love

> > the problem is that very few LLVM developers use or know anything about > Windows. > The only way for this to change is for people who do know and care about > Windows > to step forward, work on improving Windows support, and contribute their > Windows > viewpoint to design discussions etc. > As it is now, Windows users will quite likely drop LLVM because of the

Hi, I recently spent a bit of time looking into http://llvm.org/bugs/show_bug.cgi?id=12207. After talking to a bunch of different projects (including libffi and python, which is where I actually ran into issues), I found out that it seems that LLVM is in the wrong here after all. I noted such on the issue, but haven't gotten a response. There's a recent relevant thread in

Hi there, Some time ago I floated the idea of an Amsterdam LLVM Social on IRC. Feedback was positive, so I'd like to poll the list to see if there's some interest. I've picked 6 weekday nights in September, please fill out the Doodle thingy here if you're interested in attending. http://www.doodle.com/ckyv294ruhd8zpvg Cheers, Dirkjan

On Wed, Jan 16, 2013 at 8:22 AM, Tim Northover <t.p.northover at gmail.com> wrote: > I get that error when the %str type is undefined (presumably because > LLVM doesn't know its alignment requirements so can't lay out the > array$str type properly). For example, the following complete program > works correctly for me: > > %str = type {i8*, i64} > %array$str =

I'm running up against an error with this IR: %array$str = type { i64, [0 x %str] } %array.raw = call i8* @malloc(i64 %objsz) %array = bitcast i8* %array.raw to %array$str* %array.data = getelementptr %array$str* %array, i32 0, i32 1 This is kind of hand-written, but it errors out, like this: print-var.ll:50:30: error: invalid getelementptr indices %array.data = getelementptr

Hi, I'm trying to write a compiler for a language that seems useful. I decided to target LLVM and write the compiler to just print out IR as text, instead of using the API's. This allows me to focus on the IR instead of having to learn the API as well, which kind of seems like an extra obstacle at this point. Anyway, writing out IR seems like a nice enough way to learn LLVM, except that