search for: cfronted

...ols\llvm-ld\llvm-ld.cpp needs the CopyFile() invocation fix identical to gccld.cpp Also, it turns out gcc 3.3.3 in cygwin is buggy and it's unable to build some of the valid C++ code. I've just upgraded to gcc 3.4.1 and managed to build debug version of llvm successfully. I'll build cfronted and then release versions of everything and report the progress. Oleg.

Hello Chris, Sunday, October 26, 2003, 8:06:03 PM, you wrote: CL> Makes sure that you have the C front-end installed correctly, and that CL> the configure script found it (you have to provide the path to the C CL> frontend to the configure script). hm... why cross-dependency?.. I thought llvm itself doesn't use cfront-end. P.S. Chris, I guess you know, but to be sure: your

On 1/10/2013 12:11 PM, dag at cray.com wrote: > Pawel Wodnicki <root at 32bitmicro.com> writes: > >> Clang is good enough to bootstrap itself on practically >> any platform I can think of or it can be cross-bootstrapped >> if needed. > > You're completely ignoring communities that compile code outside > llvm+clang. Any compiler chosen by that group

For every level of translation [in terms of "human readable -> machine code translation", not someone translating a literary work from one language to another - although often some subtle details are lost here too], a little bit of the semantic meaning is lost. This means that you can almost never completely reconstruct the code in original form from the machine-code, or the C-code

On 11/22/2013 9:25 PM, Mikael Lyngvig wrote: > Hi guys, > > I have begun writing on a new document, named "Mapping High-Level > Constructs to LLVM IR", in which I hope to eventually explain how to > map pretty much every contemporary high-level imperative and/or OOP > language construct to LLVM IR. > > I write it for two reasons: > > 1. I need to know

Hi all, compilation of package llvm-1.0.tar.gz under redhat 9 is failed with following output: ------- make[3]: *** No rule to make target `/home/vak/llvm/llvm/runtime/GCCLibraries/crtend/BytecodeObj/C++-Exception.bc', needed by `/home/vak/llvm/llvm/lib/BytecodeLibs/libcrtend.bc'. Stop. make[3]: Leaving directory `/home/vak/llvm/llvm/runtime/GCCLibraries/crtend' ...skipped -------

On Sun, 26 Oct 2003, Valery A.Khamenya wrote: > Sunday, October 26, 2003, 8:06:03 PM, you wrote: > > CL> Makes sure that you have the C front-end installed correctly, and that > CL> the configure script found it (you have to provide the path to the C > CL> frontend to the configure script). > > hm... why cross-dependency?.. I thought llvm itself doesn't use >

On Thu, Jan 10, 2013 at 2:11 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 1/10/2013 12:11 PM, dag at cray.com wrote: > > Pawel Wodnicki <root at 32bitmicro.com> writes: > > > >> Clang is good enough to bootstrap itself on practically > >> any platform I can think of or it can be cross-bootstrapped > >> if needed. > > >

Pawel Wodnicki <root at 32bitmicro.com> writes: > Clang is good enough to bootstrap itself on practically > any platform I can think of or it can be cross-bootstrapped > if needed. You're completely ignoring communities that compile code outside llvm+clang. Any compiler chosen by that group has to be able to correctly compile hundres if not thousands of source code files.

Thanks, you have a lot of valid points there. I have myself long ago abandoned the path of using C as a backend language due to the very factors you mention. However, as I said, the document was put together in 30 minutes. Not exactly ready for prime time :-) I do agree that all of the things you mention should be described, including Lambdas, closures, and generators, but I must admit up

Hi, documentation is always good and this is a great idea. It'll be particularly useful as a place where additional examples of constructs from non-C-family languages could be added (since most compiler tutorials inevitably focus on languages that are a lot like C/C++/Obj-C). I'd imagine you've already thought of this, but it might be something where using pseudo-LLVM-IR is of the

Hi guys, I have begun writing on a new document, named "Mapping High-Level Constructs to LLVM IR", in which I hope to eventually explain how to map pretty much every contemporary high-level imperative and/or OOP language construct to LLVM IR. I write it for two reasons: 1. I need to know this stuff myself to be able to continue on my own language project. 2. I feel that this needs to

Hi David, I'm glad you like the idea :-) I've been busy and so far only lack about three or four things in the C++ area of features: Proper exception handling (which I need to understand myself first), closures (which I don't think I've ever used), and generators (which I always wondered how they were implemented). I think you are absolutely right - some day, this document will

Dear llvmdev, I am new to LLVM , but have a task on writing a LLVM backend to generate some architecture specific assembly file. Here is my cygwin build setting: GCC 3.4.4 , BIN UTILITY 2.15 ,and all other packages of the right version listed on the LLVM Getting Started doc. I have successfully built Release 1.6 LLVM. All the tools has been installed there /usr/local/bin . But I

I want to transform elf binary to llvm IR, and do some instrumentation based on llvm. Is there any tool which can do the transformation? Thanks in advance. - mudongliang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/abee5f23/attachment.html>

Hello, I have been following this discussion for a while and I think the question we should be asking is: Why do we want to even bother with all these other broken C++ compilers in a first place? Clang is good enough to bootstrap itself on practically any platform I can think of or it can be cross-bootstrapped if needed. I think usage of any language features should be decided based on

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

On 11/30/2012 6:36 PM, Lang Hames wrote: > > > RBP is used as the frame pointer on x86 (hence its automatic > appearance in your code), and shouldn't be allocated to any vreg in > function bar. Loading/saving RBP should be managed by the stack frame > setup/teardown code. > If it doesn't already, your allocator should filter out reserved > registers (See