similar to: [LLVMdev] Dragonegg in Fedora!

I'm the package maintainer for DragonEgg for Fedora. I've just tried to update the DragonEgg package for Fedora 19 beta, which uses gcc 4.8.0. I had to modify the DragonEgg Makefile because llvm-config --libs is generating the names of the static libraries, while I need to link to the dynamic library (libLLVM-3.3.so). I don't think this is the cause of my problem, but I suppose I

Fedora rawhide now builds on ARM as well as 32-bit and 64-bit x86, and while the x86 builds are successful, the ARM build is failing. I was able to fix the first problem, which was reported in a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715424 However, there are further build errors for which I haven't found appropriate fixes. It looks like there might be a namespace

The Fedora Steering Committee just approved making DragonEgg an official "feature" of Fedora 18. Previously the package was approved for inclusion in the Fedora repository, but this means that it will actually be listed as a feature in the Fedora 18 release notes. The current proposed wording for the release notes, which I hurriedly composed when I submitted the feature proposal,

Hi Eric, On 03/06/13 08:50, Eric Smith wrote: > I'm the package maintainer for DragonEgg for Fedora. I've just tried to update > the DragonEgg package for Fedora 19 beta, which uses gcc 4.8.0. > > I had to modify the DragonEgg Makefile because llvm-config --libs is generating > the names of the static libraries, while I need to link to the dynamic library >

https://fedoraproject.org/wiki/Ovirt_Node_Spin I noticed that virt-manager-tui is in rawhide finally, but the package name implies that it's not going to be in f16? virt-manager-tui.noarch 0.9.0-4.fc17 rawhide Cole, is this intentional or just smth that we need to follow up on? Also, I've noticed that ovirt-node needs refreshing... iirc apevec did tag/release of 2.0.1 from

Hello, Just a quick reminder that the November 29th (10p.m. PST) is the end of Phase 1 testing and Release Candidate 2 (RC2) deadline. After RC2 deadline, LLVM-Clang 3.2 release will be considered feature complete and no new functionality can be added. With 2 days left please use following guidelines when initiating request for patches before RC2 deadline. I will be happy to merge *approved*

Hello All, Another newbie question. I am confused as to what options will work with "fplugin-arg-dragonegg-llvm-option" for dragonegg plugin. Readme says it is used to pass command-line options to llvm. I shall consolidate into 3 questions. For all examples below, I used combo- gcc 4.6 + dragonegg(trunk) + llvm(trunk) (1). Does 'fplugin-arg-dragonegg-llvm-option' allow all

Hello All, Another newbie question. I am confused as to what options will work with "fplugin-arg-dragonegg-llvm-option" for dragonegg plugin. Readme says it is used to pass command-line options to llvm. I shall consolidate into 3 questions. For all examples below, I used combo- gcc 4.6 + dragonegg(trunk) + llvm(trunk) (1). Does 'fplugin-arg-dragonegg-llvm-option' allow all

hi Duncan, >> >>> That said, it still doesn't compile because you seem >>> to have LLVM from svn installed not llvm-2.9, and dragonegg-2.9 needs to >>> be >> >> yep, the dragonegg is also from svn when i try: /home/ether/local/gcc-4.5/bin/gcc -S -O1 -o - -fplugin=$HOME/sources/dragonegg/dragonegg.so -fplugin-arg-dragonegg-emit-ir

Akira, > Pawel, > > Is it still not too late to merge these patches? > > r168471 > r168460 > r168458 > r168456 > r168455 > r168453 > r168450 > r168448 > > These patches fix a bug in mips backend's GOT implementation and add > support for big-GOT relocations. That's quite a list of patches! To get them into the 3.2 release you would first

Looks like recent changes to Attributes.h broke the dragonegg build. I am building with latest clang and llvm trunk. clang version 3.2 (trunk 165928) (llvm/trunk 165925) Target: x86_64-unknown-linux-gnu Thread model: posix >>>>> Compiling TypeConversion.cpp /local/home/anitha/dragonegg/src/TypeConversion.cpp: In function âllvm::FunctionType* ConvertArgListToFnType(tree,

Hello, 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? Thanks, Marcus [mdaniels at dn002 dragonegg]$ cat hello.c #include <stdio.h> int hello () { printf ("Hello

On Thu, Jun 09, 2011 at 08:47:26PM -0400, Jack Howarth wrote: > Duncan, > Here are the complete benchmarks rerun against gcc 4.5.4 built with... > > Using built-in specs. > COLLECT_GCC=gfortran-fsf-4.5 > COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper > Target: x86_64-apple-darwin11.0.0 > Configured with:

Hi Jack, thanks for these numbers. Can you also please measure compile times? I'm thinking of enabling gcc optimizations by default, but I don't want to increase compile times, which means choosing a value for the -fplugin-arg-dragonegg-llvm-ir-optimize option that is low enough to get good compile times, yet high enough to get fast code. It would be great if you could play around with

Hi Jack, >>> Is there a timeline for when dragonegg might be >>> merged into gcc (4.6 perhaps)? I ask because FSF gcc >>> has allowed code in as technology previews before. >>> For instance, graphite really wasn't that usable in >>> gcc 4.4 and produced wrong code in the Polyhedron >>> 2005 benchmarks until gcc 4.5. So as long as it

Pawel, Is it still not too late to merge these patches? r168471 r168460 r168458 r168456 r168455 r168453 r168450 r168448 These patches fix a bug in mips backend's GOT implementation and add support for big-GOT relocations. Thank you. On Tue, Nov 27, 2012 at 7:35 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > Hello, > > Just a quick reminder that the November 29th

hi, I have dragonegg r131864, gcc-4.5 r174052 and llvm r131897. When i tried to make the llvm test-suite, i got a error message: /home/ether/local/gcc-4.5/bin/gcc -fplugin=/home/ether/sources/dragonegg/dragonegg.so -I/home/ether/build/llvm-ts/projects/test-suite/SingleSource/UnitTests/Vector/SSE -I/home/ether/sources/llvm/projects/test-suite/SingleSource/UnitTests/Vector/SSE

Hello All, I am in need of dragonegg support for the latest version of llvm. I tried to make dragonegg with the latest versions but it fails. It is able to be maked with the llvm version 3.3 only with GCC 4.6. I am trying this on my ubuntu system. I tried to make dragonegg with various combinations of llvm and GCC versions but the only combination which seems to be working is LLVM-3.3, GCC-4.6

Hi Tom, DragonEgg depends on GCC's and LLVM's internal headers, auto-host.h is one of them. Try to add GCC and LLVM_CONFIG with your make command as described here http://dragonegg.llvm.org/ in section "Getting it". Best, - Dima. On 12/18/2012 10:24 PM, Tom Roeder wrote: > Hi, > > I'm trying to compile release 3.2 of DragonEgg (checked out from >

Hi all, I tried using dragonegg to compile some numerical software of ours. I tried out two different approaches expecting both would yield the same results: 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a bunch of additional arguments for brevity) 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S -o test.ll test.f llc -O0 -o test.s test.ll as