similar to: [LLVMdev] LLVM / C--

 Hello,  I am French Engineer in Informatics and I would want to build a start  up to  manufacture mobile phones ( OEM level ). I am currently in discussion with investors. We would want to use LLVM as our main compiler but we will need to complete it to have a "commercial grade" one. Here are our goals : -Use a modified Elkhound as C/C++ front-end :

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

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:

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,

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)

I want to play around with the GLR support in the recent bison, so I simply fixed the skeleton. On Tue, 31 Aug 2004 07:31:25 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Mon, 2004-08-30 at 21:46, Jeff Cohen wrote: > > I'm using bison 1.875. But it worked the last time, so I don't know why > > it doesn't work now. Deleting the __attribute__ clause fixes

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

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

On Tue, 2004-08-31 at 19:52, Jeff Cohen wrote: > I want to play around with the GLR support in the recent bison, so I > simply fixed the skeleton. What do you mean by "fixed the skeleton"? Hacked the output of bison so that it compiled? I suppose what we ought to do is have a bison post-processor that scans the bison output for this problem and corrects it. Could you do that?

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

> 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

I have some questions regarding Zero Inflation Poisson models. I am using count data to analyze abundance trends of salamanders. However, I have surveys which differ in the amount of effort (i.e. the number of people searching and amount of time - I am using a museum database so not all surveys were conducted by me). Therefore I need to account for the effort. If change the count (response

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