similar to: [LLVMdev] llvm-qemu. (Was: Newbie)

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

Hi, Chris > If the assembler is a limitation, the best solution would be to add a > direct PECOFF writer. There is a start of direct ELF and Macho writers > already in the tree. They are not production quality, but could be a > useful place to start looking. Well, maybe. But in any case I doubt there will be 'open' support for CV debug format :) -- WBR, Anton

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not

Hello, Kevin. > Well, I already use custom includes with these options: "-nostdlib > -nostdinc -Ipsptoolchain/psp/include > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > GCC has some target-specific behaviour compiled in? Well, in general - yes. However, I'm not sure up to which margin. -- WBR, Anton Korobeynikov

Hello, Bill > This merge should go *much* more smoothly than the last merge -- it > could hardly be worse, right? ;-) I already did a test compile of > llvm-test with the patch and it compiled the programs without a > problem. Devang is currently testing it as well so that I have a > second opinion. One thing, which we already saw: please carefully check, that you won't

Hello, Oscar > Anyways, if there is no Mercurial or Bazaar mirrors available, I will > try git. Recommendations on which one to use welcomed. There is git mirror at repo.or.cz: http://repo.or.cz/w/llvm.git, llvm-gcc & clang mirrors are available there as well. I'm updating it 'by hands' currently due to some reasons, so sometimes it will need 2-3 days for changes in llvm

Hi, > (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" > didn't use to occur. My fault, I'll fix it. The problem is that lli wants to link in JIT module, which does not exist for these targets. -- WBR, Anton Korobeynikov

On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes? Don't mix VC runtime and libgcc. These are totally different libraries for doing

Hello, Everyone > On this specific case, IIRC, MinGW chokes if asmprinter is not on the > list of components. This may be another consequence of the malfunctoning > of llvm-config/GenLibDeps.pl on MinGW/MSYS. This works for me without any problems on mingw32. What are the problems you're seeing? -- WBR, Anton Korobeynikov

Hello, > 1. Can LLVM be used in a dynamic binary translator? Dynamic translator translators target code for an architecture (say PPC) to host code (say x86) and execute it. Yes, see llvm-qemu project (2007 GSoC). > 2. Can LLVM understand disassembled target code and generate optimized host code? No, it's not a job of LLVM. You have to convert binary code for your platform into LLVM IR

Ralph Corderoy wrote: > Hi Tilmann, > > >> Nevertheless, it is unlikely that llvm-qemu will ever be much faster >> than regular qemu (by replacing its code generator completely, which >> it currently does), which is due to the fact that regular qemu has a >> very lightweight code generator (it basically only copies blocks of >> memory and performs some

On Sep 20, 11:50 am, wbrana@gmail.com wrote: > On Sun, Sep 20, 2009 at 3:47 AM, Daniel J Blueman > > <daniel.blueman@gmail.com> wrote: > > On Sep 19, 7:20 pm, wbr...@gmail.com wrote: > > >> RAID details: > >> > >> md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1] > >> 62925824 blocks 256K chunks 2 far-copies [4/4] [UUUU] >

Hi, $ dovecot --version 2.1.7 afrer i send email: log: tail -f /var/log/* <code style='overflow:scroll'>==> sieve.log <==<br> Jan 10 20:44:14 lda(test at test.cz<a target='_blank' href='mailto:test at vinotekaolvi.cz'></a>): Error: net_connect_unix(/var/run/<wbr>dovecot/dict) failed: Permission denied (euid=2000(vmail)

Hello, Ralf > ERROR: Program used external function '__main' wich could not be > resolved! This was the bug fixed soon after 2.2 release. > I get the same error if I link the program with: "llvm-ld -v --stats > hello_world.bc -o hello_world.exe" > ... and execute the resulting "hello_world.exe" Right, because produced .exe just calls lli for bytecode

Hello, When I'm trying to play standard sound files from Asterisk using G729A codec with OH323 channel I get this message: channel.c:1650 ast_set_write_format: Unable to find a path from GSM to G729A It seems that this files must be in G729 format? How can I convert this files to G729? ... or am I wrong? -- wbr, Oleg

Hi Tilmann, > Nevertheless, it is unlikely that llvm-qemu will ever be much faster > than regular qemu (by replacing its code generator completely, which > it currently does), which is due to the fact that regular qemu has a > very lightweight code generator (it basically only copies blocks of > memory and performs some patching to them and only does static > register