similar to: [LLVMdev] regarding the high level design of GCC-LLVM

Hi ALL, Can anyone please tell me how LLVM part interact with GCC FE( i mean parser and lexer). I want to ask how and where tree data structures are converted into llvm data structures. Thanks and Regards, Manish

Hello, Everyone. I'm currently trying to bootstrap llvm-gcc4 on mingw32 platform. Everything (except some small fixes) seems to be fine: stage1 finished successfully. I'm linking with debug variant of LLVM, since linker bug prevents release builds. Unfortunately, stage2 failes immediately with this cryptic message: $/f/tmp/llvm/gccbuild/gcc/xgcc -B/f/tmp/llvm/gccbuild/gcc/

On Mon, 31 Jul 2006, Devang Patel wrote: > On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: >> Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) or does >> it go from GIMPL to LLVM? If the latter, would it be possible to allow >> some TreeSSA optimizations before emitting LLVM? > llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation

Hi Diego, >> Hopefully this is feasible, as I said I didn't work on >> it yet. > > It sounds doable, but I'm not sure why would you want to convert the > gimple into LLVM bitcode, if you are already saving LLVM bitcode in > the file. Wouldn't you be just duplicating code? here I was thinking of the possibility that some files have been compiled with -flto but

Hi Marcus, > With GCC, it is possible to compile GIMPLE from an object file back to > assembly. With Dragonegg, it seems to be a NOP. (See below for a > comparison.) > > This appears it could be a nice way to mix the strengths of GCC and > LLVM. If it worked.. Should it? I didn't have time to work on LTO with dragonegg yet, but it's on my list of things to do. What

On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: > Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) > or does it go from GIMPL to LLVM? If the latter, would it be > possible to allow some TreeSSA optimizations before emitting LLVM? llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation routines to get trees that are suitable for LLVM byte code.

> > > I suspect this is due to the recent change by Bill (revision 46747). > > > > Bill's change only affected darwin IIRC. I don't know that anyone has > > built GOMP on linux yet, and OpenMP hasn't been widely tested at all. > > I'd suggest using --enable-languages=c,c++ > > I am seeing the same errors with just building c,c++. (linux x86,

Hi Stephan, > We are developing a bounded model checker for C/C++ programs > (http://baldur.iti.kit.edu/llbmc/) that operates on LLVM's intermediate > representation. While checking a C++ program that uses STL containers > we noticed that llvm-gcc and clang handle pointer differences in > disagreeing ways. > > Consider the following C function: > int f(int *p, int *q)

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello Duncan Sands, >From your reply, what I can understand is that there is no any new OPENMP specific instructions introduced into LLVM IR as a part of DragonEgg project since GCC has already done the job of lowering OpenMP directives into GOMP runtime library calls at LOW GIMPLE IR level. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

On Feb 6, 2008, at 9:54 AM, Duncan Sands wrote: >>>> I suspect this is due to the recent change by Bill (revision >>>> 46747). >>> >>> Bill's change only affected darwin IIRC. I don't know that anyone >>> has >>> built GOMP on linux yet, and OpenMP hasn't been widely tested at >>> all. >>> I'd

Anton, I didn't know that EQUIVALENCE is the only unsupported major Fortran feature, as this bug says. Can you give me an update on the status of the Fortran front-end and what the near-term goals are? I am getting more requests from academics doing HPC compilers and it would be useful to know where Fortran support stands. Other llvmdev'ers may be interested too. Thanks,

I've read and followed the README.LLVM file that comes with LLVM-GCC 4.0 Front End source, but got the following error when compiling: configure: error: You must specify valid path to your LLVM tree with --enable-llvm=DIR make: *** [configure-gcc] Error 1 I've done the following in csh before hand: $ setenv LLVMOBJDIR /home/napi/proj/c2jvm/llvm/llvm-gcc/obj Where did I go wrong?

> I've read and followed the README.LLVM file that comes with LLVM-GCC 4.0 > Front End source, but got the following error when compiling: > > configure: error: You must specify valid path to your LLVM tree with > --enable-llvm=DIR > make: *** [configure-gcc] Error 1 > > I've done the following in csh before hand: > $ setenv LLVMOBJDIR

On Mon, Sep 13, 2010 at 04:27, Duncan Sands <baldrick at free.fr> wrote: > Hopefully this is feasible, as I said I didn't work on > it yet. It sounds doable, but I'm not sure why would you want to convert the gimple into LLVM bitcode, if you are already saving LLVM bitcode in the file. Wouldn't you be just duplicating code? Diego.

On Thu, 16 Mar 2006, Vladimir Prus wrote: > Ah, hell, as soon as I've send this email I've updated from CVS to find that > the issue was fixed by Jim several hours after I reported the crash, by > making MachineDebugInfo don't check for empty name of type. :) > Here's what I get now: > >

Vladimir Prus wrote: > So, it looks either the snapshot is not in stable state, or there's > something seriously wrong with type name handling. At this point I gave up > on quickly fixing this, so I've applied the third attached patch to LLVM, > which "fixes" this issue completely. Ah, hell, as soon as I've send this email I've updated from CVS to find that

Hi Kuan-Hsu, > gcc provides auto-vectorization on the tree-ssa framework, and llvm-gcc > uses tree-ssa to generate LLVM IR. > so, is it possible to use gcc vectorizer in LLVM? in theory yes, but you would have to modify the compiler. In llvm-gcc all gcc optimizers are turned off, and this includes the vectorizer (see the #ifdef ENABLE_LLVM clauses in gcc/passes.c), so you would have to

In trying to package up LLVM for Debian, it appears that x86_64 is no longer a supported architecture -- so, my first question is, is that correct? Best I can tell, the only thing that's supposed to work for x86_64 is the C backend. For Debian, I need to build everything from scratch. When trying to build llvm-gcc4 from source, though, I get part way through the build and am told that

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.