similar to: [LLVMdev] LLVM / Elkhound / ARM

Hello, I would want to know what are the main differences between LLVM and C--. We need a robust compiler ( or at least the most promising to work on it ) with these features : -A GLR parser (use a modified Elkhound as C/C++ front-end):   http://www.cs.berkeley.edu/~smcpeak/elkhound/ -Complete the ARM back-end -To be able to compile a complete Cross Linux from scratch for arm with uclibc-nptl.

>Neither C-- nor LLVM provide this.  Why do you need a GLR parser >specifically? http://www.cs.berkeley.edu/~smcpeak/elkhound/ Parsing with arbitrary context-free grammars has two key advantages: (1) unbounded lookahead, and (2) support for ambiguous grammars. Unbounded lookahead is achieved by allowing multiple potential parses to coexist for as long as necessary. Similarly, ambiguity

On Wednesday 19 March 2008 21:27:18 Chris Lattner wrote: > On Wed, 19 Mar 2008, Argiris Kirtzidis wrote: > > I'd like to hear your opinions and ideas for a proposal to improve > > support for C++ parsing for LLVM's clang front end. > > Some meta feedback: C++ support in clang is a huge project, far and away > more than any mortal can get done in a summer. While it

>C--'s weakness is it's incompleteness (missing many major features), >instability/bugginess, poor performance (both time to compile and the >generated code), lack of high-level optimizations, lack of ABI >compatibility with the native tools, lack of C++ frontend support, and the >small size of its community. To quote Tony Hoare : "premature optimization is the

On Wed, 19 Mar 2008, Argiris Kirtzidis wrote: > I'd like to hear your opinions and ideas for a proposal to improve > support for C++ parsing for LLVM's clang front end. Some meta feedback: C++ support in clang is a huge project, far and away more than any mortal can get done in a summer. While it would be possible to sketch out the parser itself in the summer (providing the

On 11/1/06, Guillaume FORTAINE <guillaume.fortaine at wanadoo.fr> wrote: > >C--'s weakness is it's incompleteness (missing many major features), > >instability/bugginess, poor performance (both time to compile and the > >generated code), lack of high-level optimizations, lack of ABI > >compatibility with the native tools, lack of C++ frontend support, and the

I'm linking a program (my ellsif driver) that basically brings in most of the LLVM stuff: bitcode reading, optimizations, linking, and target code generation. All of a sudden, I'm getting the following when I run: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions -O5 <premain>: CommandLine Error: Argument 'machine-licm' defined more than once!

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: > > On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I am trying to build a completely GNU free linux toolchain for the raspberry pi. > > I successfully managed to compile llvm and clang

Hi all, I'd like to hear your opinions and ideas for a proposal to improve support for C++ parsing for LLVM's clang front end. Goal: Improve clang's C++ support. The scope of the project will be limited to C++ parsing, not code generation (I think the timeframe of a GSoC project and the complexity of C++ doesn't allow full C++ support to be developed). C++ parsing support

OK, been perusing the archives and Google, but can't find what I want. I'm building up a 512 MB compact flash using the CLFS directions to build the filesystem. That works great, but I would like to use extlinux to make the cflash bootable on my little SBC. However, to date, no dice. Attached is my extlinux.conf file and the steps I have used to make this work. Initially I tried to

I am trying to understand my population abundance data and am looking into analyses of change point to try and determine, at approximately what point do populations begin to change (either decline or increasing). Can anyone offer suggestions on ways to go about this? I have looked into bcp and strucchange packages but am not completely convinced that these are appropriate for my data. Here is

Hello, I'm a French student in computing science and I'm interested in your llvm project. We plan to build a new OS design using the Mozart-Oz language ( http://hurd.gnufans.org/bin/view/Hurd/NextHurd ). Could we "easily" implement a Mozart front-end to llvm ? Do you think llvm could be a good alternative to gcc for our project ? http://www.mozart-oz.org

Hello, The Mozart-Oz isn't suitable for our project beacause of disappointing "raw" performances : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=al http://www.gecode.org/benchmarks.html I have found a very interesting language : http://www.ps.uni-sb.de/alice/ Concurrency, logic verification I found this link : http://www.cminusminus.org with a

Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. Me and my partners are currently working on a Virtualization Firmware. After an analysis of the various solutions (Citrix, VMware and Microsoft), it seemed natural to our eyes, to enable a true bare-metal hypervisor, to go as close as possible to the hardware, hence the BIOS. That's why we are currently

Hello all- First off I'm not a dev, just a small business owner trying to start up. I don't have a budget for much of anything & wind up doing most everything myself, which for the last year includes evaluating virtual infrastructure offerings. It's quite discouraging to see just how much doesn't "just work" for someone like me- unfortunately oVirt included (no