similar to: [LLVMdev] Preferring to use GCC instead of LLVM

Jon Harrop wrote: > Can you explain why you would like to generate DLLs on the > customer's computer rather than using LLVM as a JIT > compiler? Customers/clients unhappy with the inefficiency, extra CPU and RAM usage, and performance penalty of JIT. They require a faster, more efficient solution. The solution is to fully compile programs to native code at the time of

I wrote: > The Solution: Make LLVM usable as a DLL or SLL in Windoze, > capable of generating a finished ready-to-execute .EXE or > .DLL file, without requiring that MinGW or Cygwin be > installed first. Michael T. Richter replied: > You will be welcomed with open arms by the LLVM community > when you write this. I look forward to your announcement > with bated breath.

Chris Lattner wrote: > If you'd prefer to use GCC, go for it. No one is forcing > you to use LLVM. No, we would prefer to use LLVM, but a missing part in LLVM makes it difficult. It would be wonderful if this missing part could be supplied. > You are seriously ignorant of what LLVM is all about. > Please go inform yourself. Alright, I read some more on llvm.org and it

me22.ca wrote: > You said that if I have to install GCC, you might as well > just use it for everything. That statement very clearly > doesn't apply anymore, since it's binutils that's the > dependency. Or if you still stand by it, it means that > you consider GCC to also be "incomplete". How do I get the necessary binutils on Windoze? Install MinGW or

Michael T. Richter wrote: > Apparently the APIs in the LLVM docs missed your > attention. They're sneaky that way because, you know, > they just form the bulk of available documentation. I began my original message saying that I was providing "constructive criticism". That means I want to HELP if I can. Your sarcastic attitude is unprofessional. > The

On May 11, 2008, at 9:36 AM, Óscar Fuentes wrote: > > Not that I sympathize with the OP's manners but... > > Bill Wendling <isanbard at gmail.com> writes: >> >> That's only a convenience. GCC generates assembly code too and calls >> the assembler and linker as part of it's execution. You are perfectly >> able to call the assembler & linker

Is this thread suposed to be a bad joke? 2008/5/10 kr512 <kr512 at optusnet.com.au>: > > Chris Lattner wrote: >> If you'd prefer to use GCC, go for it. No one is forcing >> you to use LLVM. > > No, we would prefer to use LLVM, but a missing part in LLVM > makes it difficult. It would be wonderful if this missing > part could be supplied. > >> You

> This means that LLVM requires an assembler and linker. Call it > GCC or binutils, it is irrelevant. The OP point is that LLVM > is not a self-sufficient tool on this aspect. > > Of course, if this is a serious problem for the OP, the > correct way of dealing with it is to take constructive, polite > actions for correcting it :-) I know one compiler (Free Pascal) that

Full_Name: Steven McKinney Version: 2.6.0 OS: OS X Submission from: (NULL) (142.103.207.10) Function ar() in package "stats" is showing a quirky bug. Some calls to ar() run to completion, others throw an error. The bug is reproducible by several people on different machines, however, the ar() function itself ends up throwing the error sporadically. Several calls to ar() may be

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls

"David Greene" <dag at hpe.com> wrote: > Stefan Kanthak via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> "Michael Kruse" <llvmdev at meinersbur.de> wrote: >> >>> I think David is not referring to the capitalization of file names, but to >>> "DUPLICATE", "WASTING", "NOT AMUSED",

On Tue, 2008-05-13 at 16:30 +1000, kr512 wrote: > Michael T. Richter wrote: > > Apparently the APIs in the LLVM docs missed your > > attention. They're sneaky that way because, you know, > > they just form the bulk of available documentation. > I began my original message saying that I was providing > "constructive criticism". That means I want to

Hello, I understand that the/ demean/ argument in the *ar()* function to fit an autoregressive model selects the best AR model fitted to the mean deleted observations. What is the purpose of using this demean procedure at all? Its seems silly as the post doesn't deal with R problems.... Thanks -- View this message in context:

hello everyone: On this boring weekend, I tried compile R-trunk on windows 11 arm64 using clangarm64+msys2 on macbook m1 , it surprisingly easy to compiled and run. more investigation and test and code modify need to be done ,but IMO this is a good beginning !! to compile R on windows 11 arm64 just need : 1 svn checkout R-trunk and add USE_LLVM=YES in MKRules.dist or Mkrules.local 2 install

I'm trying to compile llvm (cvs head) on windows (WinXP sp2) using the lastest mingw, but I'm getting the link errors found below. It seems that the tools are not being linked with win32 api lib (libimagehlp.a and libpsapi.a) which defines the missing symbols. The TOOLS_VERBOSE link command is at the end of the mail and does not contain those libraries. The configure line I'm

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib

1 hour ago I downloaded llvm-3.6.0-rc4-win32.exe from http://llvm.org/pre-releases/3.6.0/ . I tried to compile simple C code that just print "hello" , but it didn't compile , because clang.exe can't find . when I use clang-cl.exe with the same code , it worked . I also have the same problem with clang++ even with , I add -I flag to GCC (4.9.1) C++ headers , the result:

Hello, I propose two small changes to spec.pgram to get modest speedup when dealing with input (x) having multiple columns. With plot = FALSE, I commonly see ~10-20% speedup, for a two column input matrix and the speedup increases for more columns with a maximum close to 45%. In the function as it currently exists, only the upper right triangle of pgram is necessary and pgram is not returned by