similar to: [LLVMdev] llvm partly ported to windows

Hello, Žiga > I would like to compile at least x86 target as well as Fibonacci example > (to test if it really works). In order to do so, I may need some hints: > 1) How to generate X86GenRegisterNames.inc required by x86 (or any other > files, if there are any other) It's being built via tablegen > 2) Is bugpoint project buildable on windows? Yes. > 3) Which other tools

On Sat, 4 Nov 2006, Reid Spencer wrote: > On Sun, 2006-11-05 at 00:27 +0300, Anton Korobeynikov wrote: > >>> 2) Is bugpoint project buildable on windows? >> Yes. > > Really? Yep. > When did that happen? Apparently Dec 22, 2005. Some rspencer guy did it: http://llvm.org/bugs/show_bug.cgi?id=351 > Are we now just execing the sub-processes > instead of

LMAO .. I don't even remember the changes I've made .. and less than a year ago. I am getting old. Reid. On Sat, 2006-11-04 at 16:50 -0800, Chris Lattner wrote: > On Sat, 4 Nov 2006, Reid Spencer wrote: > > > On Sun, 2006-11-05 at 00:27 +0300, Anton Korobeynikov wrote: > > > >>> 2) Is bugpoint project buildable on windows? > >> Yes. > > >

On Sun, 2006-11-05 at 00:27 +0300, Anton Korobeynikov wrote: > > 2) Is bugpoint project buildable on windows? > Yes. Really? When did that happen? Are we now just execing the sub-processes instead of forking them? Reid.

Hello, Aaron. > /usr/src/llvm-gcc4/gcc/libgcc2.c: In function '__eprintf': > /usr/src/llvm-gcc4/gcc/libgcc2.c:1832: internal compiler error: > Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. You should: 1. Try to emit bytecode with --emit-llvm compiler switch. 1.1

Hello (again)! I fixed most of the system and the following projects compile now: * Analysis * AsmParser * Bytecode * CBeckend * Codegen * ExecutionEngine * Support * System * TableGen * Target * Transforms * VMCore I would like to compile at least x86 target as well as Fibonacci example (to test if it really works). In order to do so, I may need some hints: 1) How to generate

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

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

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

I tried to ask for 32 and that didn't seem to help. MallocInst also seemed to ignore the 16 byte directive. For now, I'm just issuing all my loads as unaligned and that's working ok. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 10:35 AM To: asl at

On 8/29/07, Bill Wendling <isanbard at gmail.com> wrote: > On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > Hello, Bill > > > > > It may be my lack of understanding, but it appears that having -- > > > enable-eh set during compilation of llvm-gcc is causing extra files > > > to be compiled. > > Oh, no. They are always

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Bill, > When I try to compile on Darwin now, I get this: Could you please provide LLVM bytecode, where bug is reproducible with llc? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, David > bugpoint now works for remote ARM if you run it directly from the > command line. It doesn't work correctly when invoked from the test > makefile because envvar PWD is being set to /bin/pwd and so causing > GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going > on with that, perhaps something in the makefile hierarchy is setting > PWD to

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call,