similar to: [LLVMdev] speeding up compilation and link time

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

Does anyone have any ideas or tips on how to shorten the time to build? I am building a new tool (in the llvm/projects directory) and it takes minutes to fully build the project, possibly because it uses lots of templates and boost & stl libraries and I am using a slow machine. Specifically, I am looking for ways to change the Makefile and use precompiled headers and incremental linking, but

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

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, Ted > __main is supposed to be inside hello.bc, so why can�t lli find it? No, it shouldn't be there. On targets, which lacks init sections (for example, all win-based, like mingw & cygwin) __main is used to call static constructors and relevant stuff. The call to __main is assembled early in the main routine before the actual code will be executed. I'll try to look into

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

Anton Korobeynikov wrote: > Hello, Jonathan > > >> I thought I'd messed up something related to the linker, >> but I couldn't explain why XP would work using the same steps. >> > The only thing comes to my mind seeing this: perl from msysDTK works > differently (somehow) on Vista, thus llvm-config is broken which leads > to missed libraries,

Hello, Jonathan > I thought I'd messed up something related to the linker, > but I couldn't explain why XP would work using the same steps. The only thing comes to my mind seeing this: perl from msysDTK works differently (somehow) on Vista, thus llvm-config is broken which leads to missed libraries, broken dependencies, etc. I'd suggest you to compare stuff on different

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

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