similar to: [LLVMdev] First Pass at building dragon egg-3.3 for clang 3.3 - using gcc-4.7

Duncan, Many thanks for your comments. The core issue we're running into is this: $ GCC=/usr/bin/gcc LLVM_CONFIG=/usr/bin/llvm-config make Compiling utils/TargetInfo.cpp Linking TargetInfo ld: fatal: library -lLLVMSupport: not found ld: fatal: file processing errors. No output written to TargetInfo collect2: error: ld returned 1 exit statusAll other gyrations are attempts to shoehorn

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

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 Peter, > Why not do this too? I've applied this - thanks for the patch! Ciao, Duncan.

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

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

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

On Tue, Apr 13, 2010 at 04:06:45PM +0200, Duncan Sands wrote: > 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

Hi Gregory, > Ah, non-unicode email... In the llvm output there should be a "1" character, > i.e. (char) 0x01, prepended to acos and __GI_acos. I'm unable to get it on > smaller things, but it happens when I try to compile uClibc with llvm. I've > attached the .o and the .bc for comparison. The text file is the result after > preprocessing (to avoid having to

On Tue, Apr 13, 2010 at 09:01:16AM +0200, Duncan Sands wrote: > 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. Duncan,

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 Gregory, > I'm looking at compiling some pieces of the standard library with llvm but I'm > running into problems with some functions being renamed by dragonegg. For > example, when I compile the acos implementation with plain gcc I get: > > $ nm acos.o > 0000000000000000 r .LC1 > 0000000000000048 r .LC10 > 0000000000000050 r .LC11 > 0000000000000058 r .LC12

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

Hello, I'm looking at compiling some pieces of the standard library with llvm but I'm running into problems with some functions being renamed by dragonegg. For example, when I compile the acos implementation with plain gcc I get: $ nm acos.o 0000000000000000 r .LC1 0000000000000048 r .LC10 0000000000000050 r .LC11 0000000000000058 r .LC12 0000000000000060 r .LC13 0000000000000068 r .LC14

Hi Duncan, Ah, non-unicode email... In the llvm output there should be a "1" character, i.e. (char) 0x01, prepended to acos and __GI_acos. I'm unable to get it on smaller things, but it happens when I try to compile uClibc with llvm. I've attached the .o and the .bc for comparison. The text file is the result after preprocessing (to avoid having to download a bunch of stuff).

hi! I would like to know if it is feasible to use the dragon egg gcc plugin to automatically convert fortran code to c. Having found that it is possible to output llvm byte code back to c (at least something like this gave me this impression/hope: llc -march=c -o test.c) I am hoping to use dragon egg to generate the byte code from fortran 90 which than output to c. Does this seem feasible at