search for: tromey

...Stop. Obviously, somthing fails here when calling the autogen-Script. I have a /usr/local-installation of automake, which is Version 1.9, this thing also provides me aclocal version 1.9: bjoern@deimos:~/studium/beleg/resources/svn/speex$ aclocal --version aclocal (GNU automake) 1.9 Written by Tom Tromey <tromey@redhat.com> Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bjoern@deimos:~/studium/beleg/resources/svn/speex$ automake --version au...

...ls here when calling the autogen-Script. I have a > /usr/local-installation of automake, which is Version 1.9, this thing > also provides me aclocal version 1.9: > > bjoern@deimos:~/studium/beleg/resources/svn/speex$ aclocal --version > aclocal (GNU automake) 1.9 > Written by Tom Tromey <tromey@redhat.com> > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > bjoern@deimos:~/studium/beleg/resources/svn/speex$ a...

...e autogen-Script. I have a >> /usr/local-installation of automake, which is Version 1.9, this thing >> also provides me aclocal version 1.9: >> >> bjoern@deimos:~/studium/beleg/resources/svn/speex$ aclocal --version >> aclocal (GNU automake) 1.9 >> Written by Tom Tromey <tromey@redhat.com> >> Copyright (C) 2004 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> bjoern@deimos:~/studium/beleg/resour...

...al (GNU automake) 1.14.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey at redhat.com> and Alexandre Duret-Lutz <adl at gnu.org>. # aclocal configure.ac:319: warning: macro 'AM_ICONV' not found in library # autoconf configure.ac:319: error: possibly undefined macro: AM_ICONV If this token and others are legitimate, please use...

Folks, Last week Tom Tromey posted an idea on his blog about executable .desktop files: http://tromey.com/blog/?p=285 I saw it, thought it was a good idea, and commented as much on my blog: http://sniping.org/2006/09/28/so-simple-it-might-just-be-worth- implementing/ To this end, I've written an additional ut...

Tom Tromey wrote: > Archie> Perhaps it is. In which case, I guess we need something better or else > Archie> we'll never be able to do certain optimizations. > > I'm curious to know which optimizations you have in mind. E.g. devirtualization: this requires knowing the Java type (no...

On Apr 26, 2006, at 3:06 PM, Tom Tromey wrote: > So until this is fixed the JIT for libgcj is more or less an > experimental toy. Ok, I understand, though it is unfortunate. I don't have any great insights into fixing this. > I'm going to keep developing it as an add-on for libgcj. > Hopefully I'll be able t...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> Perhaps it is. In which case, I guess we need something better or else Archie> we'll never be able to do certain optimizations. I'm curious to know which optimizations you have in mind. Tom

...as built it yet? I am willing to provide such a binary. Is it already too late? What do I have to do? How can you trust me / my binary? Thanks for the great 3.8 release, Christoph -- GDB does hate your application, expresses its contempt through the design of its command-line interface. -- Tom Tromey, FOSDEM 2014

On 29 Apr 2006 20:38:58 -0600, Tom Tromey <tromey at redhat.com> wrote: > >>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > >> In the JIT, devirtualization looks doable, though somewhat fiddly. At > >> least, that is true for straightforward things like calls t...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: >> In the JIT, devirtualization looks doable, though somewhat fiddly. At >> least, that is true for straightforward things like calls to methods >> in final classes, or calls to methods on objects allocated with 'new' >> in the current function. (The latter could be

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> In JCVM for example, there is a bit in type->flags that Archie> determines whether the class is initialized or not. This bit Archie> has to be checked before every static method invocation or Archie> static field access. You could reserve an entire byte instead Archie> of a

I am working on getting the CentOS 3/Red Hat Enterprise 3 buildbot going, but I have hit a problem with the latest SVN build. Running './configure' works without any errors, (but I do note that it takes a long time on the drivers directory Makefile). Here is a copy of the configuration summary: Configuration summary: enable SSL development code: yes enable IPv6 support: yes build CGI

...#39;s a more direct way: For each vtable DIE, link to the concrete type it represents. Now you just go from vtable object to concrete type with no string lookup, which is faster, doesnt' require linkage names, doesn't depend on demanglers matching, etc. As an added bonus: This is what Tom Tromey already added to Rust to do this. So it's even been implemented before. On Sat, Mar 3, 2018 at 8:20 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >&gt...

I recently wrote an LLVM-based JIT plugin for libgcj and I thought it'd be worthwhile to mention it here. It is in cvs on sourceforge, but afaics anonymous cvs there is pretty broken at the moment... so if you want a copy, ask and I will email it to you. Basically I hacked libgcj to (optionally) dynamically load JIT module at startup. If a JIT is loaded then bytecode is passed to it rather

On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote: >>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: > > Vikram> Either way, one issue that you will have to deal with is > preserving > Vikram> the behavior of Java exceptions (assuming you care about > that). LLVM > V...

On Tue, 12 Aug 2008, Chris Lattner wrote: > > On Aug 12, 2008, at 10:55 AM, Tom Tromey wrote: > >>>>>>> "Tom" == Tom Quarendon <tom at quarendon.net> writes: >> >> Tom> I imagine that GCJ has do to this ind of thing? >> >> FWIW, libgcj does not include a JIT compiler. >> So, no solution there, sorry. > >...

I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, and switched llvm-gcc over to use it. This class is based on feedback Tom Tromey gave on LLVM way back here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-April/005581.html Basically, when creating a frontend, you end up creating a lot of instructions. This has three suboptimal aspects to it: 1. The constructors for the instructions all must be passed a place to inse...

>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: Vikram> Ok, this makes sense. But I was actually asking how you deal with Vikram> this in the LLVM JIT for libgcj (I guess it is too early for you to Vikram> have an answer). Yeah. I completely punted on exception handling in general, since at the moment there is really no hope for integrating

>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: Vikram> Either way, one issue that you will have to deal with is preserving Vikram> the behavior of Java exceptions (assuming you care about that). LLVM Vikram> does not preserve the order of potentially excepting instructions Vikram> (e.g., a divide or a load). This would have to be handled