search for: cfront

...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.

...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 `Sender' is llvmdev-admin at cs.uiuc.edu -- Best regards, Valery A.Khamenya mailto:khamenya at mail.ru Local Time: 22:32

...however broken C++ compiler to build LLVM and stay compatible with the platform compiler then perhaps we should approach it differently. Ideally source translation in clang could be used to "lower" C++11 code to either C++03 or even C++98, worst case just use CPP backend. I realize that Cfront approach does not have a good track record but this could be a C++front translating C++11 to older version of the C++ language. Paweł

...other - 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 from the LLVM IR, or the C++ code from the output of something like cfront (the original C++ -> C translator), or the original Pascal code from a Pascal to C compiler, etc. It is, at least sometimes, possible to reconstruct something that can then be "compiled" [in quotes as it's a loose term in this discussion] again from the binary file, but it's o...

...en C to IR is a poor idea. C is in some ways an extremely limited language (no native exception handling constructs, e.g.). If you want to be a guide to how to lower languages to LLVM IR, you need to also explain how to take advantage of features in the IR to optimize code better (e.g., TBAA). Cfront-like C++ compilers are extremely rare-to-nonexistent (in part because it is difficult to map some features, most notably exception handling, cleanly and efficiently into C); if your guide is describing such an approach, it reads like an implicit endorsement. It is possible to describe some aspe...

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 -------

...> > 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. LLVM itself doesn't. The files that live in the llvm/runtime directory are runtime libraries for the C/C++ front-end. If you're not using those front-ends, then you don't need to build them. In a cruel twist of fate, they are _WRITTEN_ in C/C++, hence the dependency on the fron...

...gt; to build LLVM and stay compatible with the platform compiler > then perhaps we should approach it differently. Ideally source > translation in clang could be used to "lower" C++11 code to > either C++03 or even C++98, worst case just use CPP backend. > > I realize that Cfront approach does not have a good > track record but this could be a C++front translating > C++11 to older version of the C++ language. > I wouldn't expect this to be a part of LLVM itself; if someone needs to support an old/broken compiler, they can make this work themselves. > >...

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.

...gt; a poor idea. C is in some ways an extremely limited language (no native > exception handling constructs, e.g.). If you want to be a guide to how to > lower languages to LLVM IR, you need to also explain how to take advantage > of features in the IR to optimize code better (e.g., TBAA). Cfront-like C++ > compilers are extremely rare-to-nonexistent (in part because it is > difficult to map some features, most notably exception handling, cleanly > and efficiently into C); if your guide is describing such an approach, it > reads like an implicit endorsement. It is possible to de...

...dea. C is in some ways an extremely limited language (no native >> exception handling constructs, e.g.). If you want to be a guide to how to >> lower languages to LLVM IR, you need to also explain how to take advantage >> of features in the IR to optimize code better (e.g., TBAA). Cfront-like C++ >> compilers are extremely rare-to-nonexistent (in part because it is >> difficult to map some features, most notably exception handling, cleanly >> and efficiently into C); if your guide is describing such an approach, it >> reads like an implicit endorsement. It i...

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

...some ways an extremely limited language (no native >>> exception handling constructs, e.g.). If you want to be a guide to how to >>> lower languages to LLVM IR, you need to also explain how to take advantage >>> of features in the IR to optimize code better (e.g., TBAA). Cfront-like C++ >>> compilers are extremely rare-to-nonexistent (in part because it is >>> difficult to map some features, most notably exception handling, cleanly >>> and efficiently into C); if your guide is describing such an approach, it >>> reads like an implicit e...

...e. 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 have problem with building LLVM-Cfrontend that comes with this Release. CFrontend build stopped after these lines -------------------------------------------------------------------------- gcc -O2 -DIN_GCC -DDEFAULT_TARGET_MACHINE=\"i686-pc-cygwin\" -W -Wall -Wwrit e-strings -Wstrict-prototypes -Wmissing-prototypes -pe...

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

..." */", "", "#define FLEX_SCANNER", "#define YY_FLEX_MAJOR_VERSION 2", "#define YY_FLEX_MINOR_VERSION 5", "", "%-", "#include <stdio.h>", "%*", "", "", "/* cfront 1.2 defines \"c_plusplus\" instead of \"__cplusplus\" */", "#ifdef c_plusplus", "#ifndef __cplusplus", "#define __cplusplus", "#endif", "#endif", "", "", "#ifdef __cplusplus",...