similar to: [LLVMdev] dragon egg + llvm for fortran to c translation

Thank you for your reply Dmitry! It would not be too great a deal, if I need to use previous versions as long as it would get the desired results :) Would the code from the IR be portable to different C compilers? I guess the resulting C code will not have too much resemblance to the input? cheers Philipp On 03/01/2013 05:02 PM, Dmitry Mikushin wrote: > DragonEgg only converts GCC's IR

Hi Philipp, Let me provide you with an example back from September 2011. Attached is original Fortran source, optimized LLVM IR and what we regenerated back into C from LLVM IR by means of C backend. As you can see, the C code closely resembles LLVM IR. I don't know what you intend to use it for (maybe some source-to-source compiler or DSL?), but to our experience, we had a system using C

DragonEgg only converts GCC's IR to LLVM IR. And -march=c is C backend. We used it for a while last year, but its support has been dropped several months ago. There are people, who are still using it privately, as far as I know. - D. 2013/3/1 Philipp Schwaha <philipp at schwaha.net> > hi! > > I would like to know if it is feasible to use the dragon egg gcc plugin to >

Hi Peter, > Why not do this too? I've applied this - thanks for the patch! Ciao, Duncan.

Hi Jack, > bash-3.2$ gcc-4 hello.c -S -O1 -o - -fplugin=./dragonegg.so > cc1: error: Cannot load plugin ./dragonegg.so > dlopen(./dragonegg.so, 10): Symbol not found: _classify_argument looks like you forgot to apply the i386_static.diff patch to gcc. Ciao, Duncan.

Peter, FYI, I am interested in dragon-egg because I have been preparing updated llvm/llvm-gcc42 2.7 packaging for fink and was considering adding in an addition dragon-egg package if the additional gcc patch didn't destablize gcc45. Also I am really interested in checking the Polyhedron 2005 benchmarks for gcc 4.5.0 with and without dragon-egg. The Polyhedron 2005 benchmarks improved about

On Sun, Apr 11, 2010 at 10:29:28AM +0200, Duncan Sands wrote: > Hi Jack, > >> bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make >> g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100954M\"

Hi Jack, > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100954M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg

Duncan, Do a quick check here on x86_64-apple-darwin10 with svn llvm and svn dragon-egg against release gcc 4.5.0, the results from the himenoBMTxpa benchmark compiled at -O3 look pretty good. With stock gcc-4.5.0, we get... Grid-size = M mimax = 128 mjmax = 128 mkmax = 256 imax = 127 jmax = 127 kmax =255 Start rehearsal measurement process. Measure the performance in 3 times. MFLOPS:

Hi Jack, > Is anyone building dragon-egg on darwin? Anton built it once. There were some problems with dynamic libraries: gcc's plugin support requires the use of dynamic libraries, and the configure logic it uses thinks that darwin does not support dynamic libraries! So it is possible that plugin support was automatically disabled because of this. Try configuring with

On Sat, Apr 10, 2010 at 08:29:07PM -0500, Peter O'Gorman wrote: > On 04/10/2010 08:01 PM, Jack Howarth wrote: > > > > > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD

Hi Peter, > Why not do this too? can this be extracted out of llvm-config somehow? Ciao, Duncan.

On 04/12/2010 10:31 AM, Duncan Sands wrote: > Hi Peter, > >> Why not do this too? > > can this be extracted out of llvm-config somehow? > Hi, Doesn't look like llvm-config has this info. Peter

Hello Team, Good Morning!! This is Vishnu Prasanth doing my master's thesis on improving llvm compiler optimization. Currently I am trying to build dragon egg and when I gave take, it is not getting recognized for ARM machine. Can you please help me with. Below are the errors when I gave the below command inside dragon egg directory GCC=GCC_DIR/gcc

On Sat, Apr 10, 2010 at 01:52:18PM +0200, Duncan Sands wrote: > Hi Jack, > > > Is anyone building dragon-egg on darwin? > > Anton built it once. There were some problems with dynamic libraries: gcc's > plugin support requires the use of dynamic libraries, and the configure logic > it uses thinks that darwin does not support dynamic libraries! So it is >

On 04/10/2010 08:01 PM, Jack Howarth wrote: > > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100954M\"

Is anyone building dragon-egg on darwin? I am trying to build against the fink gcc45 package that I have prepared for darwin and a updated fink llvm 2.7 package that is built as... ../llvm-2.7/configure --prefix=/sw --prefix=/sw/lib/llvm --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-as=/Developer/usr/bin/as

Hi Peter, > After editing the dragonegg Makefile to remove -Werror, ... I think I'm going to remove -Werror, and instead make the build less noisy so warnings are easier to see. Ciao, Duncan.

On 04/11/2010 03:31 AM, Duncan Sands wrote: > Hi Peter, > >> After editing the dragonegg Makefile to remove -Werror, ... > > I think I'm going to remove -Werror, and instead make the build less > noisy so warnings are easier to see. That's nicer! Thank you. Why not do this too? Peter -------------- next part -------------- A non-text attachment was scrubbed...

Hi Jack, > Doesn't i386_static.diff represent a violation of... > > https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications > > since it first declares a function as extern and then > redefines it locally? I don't think so. "Redefines it locally" is not the same as giving