similar to: [LLVMdev] LLVM capability question.

I'm trying to get LLVM1.9 working on my Ubuntu 6.10 system. The LLVM version in the repositories is 1.7 and I've never managed to get it successfully working because whoever packaged it thought it would be fun to rename everything. This means I can't use it to build 1.9 and I've therefore decided to try bootstrapping a 1.9 build. Yes, I've looked at the docs where it said

On Tue, 2007-16-01 at 02:50 +0000, Reid Spencer wrote: > > The build instructions provided tell me to build llvm-gcc first from > > the source. > > The source for that tells me to build llvm first from the source. I'm > > not sure where to go from this point. > You should build llvm first, then llvm-gcc. When I build LLVM first, however, I get told that it

Hi Michael, On Tue, 2007-01-16 at 13:13 +0800, Michael T. Richter wrote: > On Tue, 2007-16-01 at 02:50 +0000, Reid Spencer wrote: > > > The build instructions provided tell me to build llvm-gcc first from > > > the source. > > > The source for that tells me to build llvm first from the source. I'm > > > not sure where to go from this point. >

Hi Michael, On Tue, 2007-01-16 at 10:24 +0800, Michael T. Richter wrote: > I'm trying to get LLVM1.9 working on my Ubuntu 6.10 system. The LLVM > version in the repositories is 1.7 and I've never managed to get it > successfully working because whoever packaged it thought it would be > fun to rename everything. This means I can't use it to build 1.9 and > I've

http://snakeratpig.blogspot.com/2008/02/alternative-compiler-suites.html Executive summary: LLVM-GCC was consistently faster and its output consistently faster than plain old GCC when compiling and using Ruby 1.9. Both compilers failed spectacularly on the full regression suite, but GCC lasted longer and did more tests before exploding. If I could find a comprehensive Erlang testing suite,

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

I'm getting behaviour I don't understand from my attempt to build the GCC front end under Ubuntu Edgy. Everything seems to work fine until I hit this: stage1/xgcc -Bstage1/ -B/home/michael/software/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic

Thanks for your replies. This is indeed a helpful mailing list. I made some more researches about the licensing issue and this is what I discovered: - from FSF it seems that packaging together a GPL application and a commercial one it is a corner case of licensing. Here is what they say: http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation

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.

Hi Michael, thanks for trying out LLVM! "The bad news comes with the make test-all results. Less than two minutes into the comprehensive test suite the LLVM-GCC version of Ruby 1.9 dies with the following message: "Illegal instruction (core dumped)". Later it tells me the test failed with "error 132". This is, as you can see, not a very useful message since it's not

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

Hi Steve, I'm not an LLVM developer but am the author/maintainer of the LLVM backend in GHC. The patch looks mostly good to me (although I am not that familiar with ARM so could easily have missed something). My main concern is why are you avoiding using the R0 - R3 registers? Also, could you please update me on the status of this work. I assume you are getting GHC running in registerised

TL;DR: I'm trying to evaluate if LLD can be used with GHC (Glasgow Haskell Compiler) on Windows. Haskell binary code is usually deployed in "packages". A package typically provides static library(ies) and optionally – shared library(ies) and/or prelinked ('ld -r') object file. The latter is the best way to satisfy GHC runtime linker, since it requires no separate

On 10/10/2017 9:00 PM, Rui Ueyama wrote: > I'm not sure if I understand correctly. If my understanding is > correct, you are saying that GHC can link either .o or .so at runtime, > which sounds a bit odd because .o is not designed for dynamic linking. > Am I missing something? Yes, GHC runtime linker *does* link .o files not only doing all necessary relocations but also

All, I would like to submit the attached patch, which allows the GHC (Glasgow Haskell Compiler) calling convention to work on ARM targets. Could some nice person please review this code, so I can move towards getting it committed? I have thoroughly tested this patch again GHC on a Debian-ARM (armel) system. Unfortunately my understanding of LLVM is limited, so it's likely I'm not

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will

David, Thanks for that - I emailed Karel Gardas. I've got GHC successfully registerised on ARM, and I'm just starting on pushing it upstream. The reason why I'm avoiding the R0-R3 registers is mainly because my qemu-based ARM VM takes days to compile everything, and I was being conservative. The GHC code can call directly out to C, so it would need to save its own R0-R3 when it

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

On May 13, 2008, at 10:04 PM, Razvan Aciu wrote: > Thanks for your replies. This is indeed a helpful mailing list. I > made some > more researches about the licensing issue and this is what I > discovered: > For now, I think for a commercial developer who wants to create a > complete > compiler toolchain using llvm, trying to package its compiler with > GCC is a

Hello, first of all: one of the LLVM 3.0 new feature was a support for GHC specific calling convention on ARM platform. It looks like this support was merged just into 3.0 branch, specifically it appeared in 3.0 RC2. Anyway, I hope this is just a mistake or omission that such support was merged only into 3.0 and not also into HEAD. I've just found it by testing LLVM 3.1 with GHC 7.4.2 and