similar to: [LLVMdev] LLVM for functional languages?

Hi! Essential Haskell Compiler (EHC) also has llvm backend. http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM Cheers, Csaba -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090118/33489dd6/attachment.html>

I'm having a problem rebuilding a package, new to me in R 2.15.0 (Linux) It hits all that contain the line \usepackage[pdftex]{graphics} and leads to the following when running R CMD check on the directory. (I do this often; a final run on the tar.gz file will happen before submission.) Since I float and resize my figures, removing the line is fatal in other ways.

/lib/System/platform/Path.cpp is not compilable under Cygwin (although it was motivated to be for Cygwin...): ----------------------------------- Compiling Path.cpp In file included from Path.cpp:37: platform/Path.cpp: In static member function `static llvm::sys::Path llvm::sys::Path::GetTemporaryDirectory()': platform/Path.cpp:41: error: `mkdtemp' undeclared (first use this function)

Hi, This is probably an easy question, but I could not find the answer to it. I'm working on a LLVM back-end for the EHC compiler (a Haskell compiler). Currently there is a C back-end and I would like to reuse the primitive library functions from this back-end. So I have compiled C sources in a .o file and I would like to call these from my LLVM code. If I declare these primitive functions

Assuming the run-time library is in C, is there a reason why you cannot also compile that to LLVM? You could get significantly better optimization via LTO that way. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Dec 8, 2007, at 12:12 AM, Chris Lattner wrote: > > On Dec 7, 2007, at 6:38 AM, John van Schie wrote: > >> Hi, >> >> This is probably an easy

On Dec 7, 2007, at 6:38 AM, John van Schie wrote: > Hi, > > This is probably an easy question, but I could not find the answer > to it. > > I'm working on a LLVM back-end for the EHC compiler (a Haskell > compiler). Currently there is a C back-end and I would like to reuse > the > primitive library functions from this back-end. Ok. > > So I have compiled

Hi people, I have a Linux box running Samba 3.0.2a in ADS mode MIT Kerberos 1.3.3. My W2K e WXP users can't access the linux box by netbios name, the only access that works is by IP address, I know that's caused because access thought IP address don't make use of Kerberos. The most strange for me it's that the same environment works fine with a W2K Active Directory, I read in same

Hi Andy, Andrew Trick wrote: >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at arm.com <mailto:Christof.Douma at arm.com>> wrote: >> >> I can’t help to ask. Why not define a wrapping nsw instruction as UB, instead of “delayed UB” aka poison? I believe we >> have the notion of poison solely to ease the movement of instructions. In my example

Hi Jim, I did what the doc says but the problem is the same. Does anybody saw this work ? I mean, is the Samba 3.0.2a+Kerberos MIT 1.3.3 able to be accessed by a WXP, W2K or W2K3 machine, using Kerberos tickets generated in a Windows 2003 KDC (W2K3 AD) ? Thanks -----Mensagem original----- De: Jim McDonough [mailto:jmcd@us.ibm.com] Enviada em: segunda-feira, 19 de abril de 2004 17:07 Para:

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics

On Jan 17, 2009, at 1:25 PM, Albert Graef wrote: > Chris Lattner wrote: >> In the end, I consider this to be a yet-another chapter in the >> "functional language people don't like LLVM" saga. > > Yet another counterexample: > > http://pure-lang.googlecode.com/ Hey, this is incredibly cool. I had never heard of pure, nice work! Would you mind writing a

Chris Lattner wrote: > In the end, I consider this to be a yet-another chapter in the > "functional language people don't like LLVM" saga. Yet another counterexample: http://pure-lang.googlecode.com/ LLVM from the ground up, proper tail calls, interactive interpreter, JIT, easy C interface. Works great. :) Without LLVM, I could have never pulled that off in a couple of

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote: > Misha Brukman wrote: > >>1. Opcodes and intrinsics > >> > > That's not really correct. The intrinsics such as llvm.frameaddress and > > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > > the intrinsics is specifically machine-dependent, and LLVM (and its > > opcodes) are

Thanks for noting it. I'll see what cygwin has to offer in this area and correct the implementation. Thanks, Reid. On Wed, 2004-09-01 at 09:11, Valery A.Khamenya wrote: > /lib/System/platform/Path.cpp is not compilable under Cygwin > (although it was motivated to be for Cygwin...): > ----------------------------------- > Compiling Path.cpp > In file included from

Hello CentOS ! Iam trying to configure a Dual Core 1.6Ghz AMD E-350 machine to be able NIC (eth0) interrupts the most efficient way possible so that I can be able to handle the large number of random source packets per second. Currently running CentOS 6.4 2.6.32-358.6.2.el6.x86_64, i made some load testing with a random sourced syn flood to the NIC of this machine and found out according to

Reid, >As for Interix support in general, I'm having a hard time determining >which variant of Unix Interix implements. It seems to be partially Posix >1 and partially Posix 2 based. Do you have any further information >related to the specific standards supported by Interix? I don't want to >incorrectly categorize the Interix support. I've discussed this subject with

On Nov 5, 2007, at 19:19, Christophe de Dinechin wrote: > I'm trying to port the XL compiler (http://xlr.sf.net) to use the > LLVM back-end. So far, little trouble doing so. But there is one > aspect of the semantics of the LLVM IR that surprises me. Why are > the call, declare and define "halfway through" ABI conventions? > > I think it's the right thing

LegalizeDAG.cpp SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { case ISD::RET: Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. switch (Node->getNumOperands()) { case 2: // ret val [skipped] case 1: // ret void [skipped] default: { // ret <values> [skipped] Does it imply that a ret instruction may

Hello, I'm trying to port the XL compiler (http://xlr.sf.net) to use the LLVM back-end. So far, little trouble doing so. But there is one aspect of the semantics of the LLVM IR that surprises me. Why are the call, declare and define "halfway through" ABI conventions? I think it's the right thing to have a single high level node for each call, as opposed to separate

Apologies: didn't notice how old this thread is before replying. On Tue, Mar 22, 2016 at 5:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Vivek, > > [+CC Matthias, Quentin] > > Inter-procedural register allocation can be a big win, but my estimate > is that it will be challenging to complete within one summer unless > you're already familiar