similar to: [LLVMdev] Windows x64 support

Hi Anton, Thanks for the heads up. I've only encountered this bug though, and my workaround fixes x64 for me. Could you maybe sum up the other remaining issues? Anyhow, is there any reason why my workaround is not fit for committing? It works wonderfully for me and I see little reason to hold it back. Currently I have to patch it every time I do an update. Thanks, Nicolas -----Original

Hi Nicolas, > never got committed entirely so things are still broken. It should probably > be reopened, have my workaround committed, and then later a proper fix that > doesn't cost (a tiny bit of) performance could be done. This is only the tip of the iceberg, unfortunately. There are others more severe ABI incompatibilities. -- WBR, Anton Korobeynikov

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

Hi, Nicholas > Anyway, my questions are as follows: Is x64 JIT on Windows supposed to work currently? No, I know at least 3 things preventing it from full ABI compliance. > If not, is x64 JIT on Windows a LLVM development goal? Yes. > And if so, is there a time-line or roadmap for achieving such a goal? Not yet, this will require some huge changes in generic CC handling code. I hope,

Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think

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

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

Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov

> The x86-64 one probably doesn't work for Winodws. That's likely the > issue. Well, x86-64 stub was never ported to intel assembler, I expect to see 32-bit one used on windows64. In general, the whole windows64 support is missed mainly due to crazy calling convetion invented by Microsoft. So, all calls from code being JITed to external functions will be clearly broken (if they

Hello, Evan > I think a Win64 version of X86CompilationCallback{2} is still needed. > Also, it's not clear to me how to force a non-Windows CC. It may > require some FE extension to support it? Well, as currently we don't have windows64 support in FE correct (non-windows) CC will be set automatically. -- WBR, Anton Korobeynikov

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, 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

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and