darwin dragon-egg build issues

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 --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only

Since the gcc45 package installs symlinks to the compilers
in /sw/bin as gcc-4, g++-4, etc, I executed...

GCC=/sw/bin/gcc-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

This fails with...

g++ -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual /Users/howarth/llvm_svn/dragonegg/utils/target.cpp
<command-line>: error: "__STDC_LIMIT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
<command-line>: error: "__STDC_CONSTANT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
make: *** [target.o] Error 1

with GCC apparently being insufficent to redirect the compilers. Instead, I had to use...

GCC=/sw/bin/gcc-4 CC=/sw/bin/gcc-4 CXX=/sw/bin/g++-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

This however fails with...

/sw/bin/gcc-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=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -I/Users/howarth/llvm_svn/dragonegg/x86 -I/Users/howarth/llvm_svn/dragonegg/darwin -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-common /Users/howarth/llvm_svn/dragonegg/llvm-cache.c
In file included from /Users/howarth/llvm_svn/dragonegg/llvm-cache.c:28:0:
/Users/howarth/llvm_svn/dragonegg/llvm-cache.h:31:20: fatal error: config.h: No such file or directory
compilation terminated.
make: *** [llvm-cache.o] Error 1

If I manually run /sw/lib/llvm/bin/llvm-config, I get...

bash-3.2$ /sw/lib/llvm/bin/llvm-config --prefix
/sw/lib/llvm
bash-3.2$ /sw/lib/llvm/bin/llvm-config --src-root
/sw/src/fink.build/llvm-2.7-1/llvm-2.7
bash-3.2$ /sw/lib/llvm/bin/llvm-config --obj-root
/sw/src/fink.build/llvm-2.7-1/llvm_objdir
bash-3.2$ /sw/lib/llvm/bin/llvm-config --bindir
/sw/lib/llvm/bin
bash-3.2$ /sw/lib/llvm/bin/llvm-config --includedir
/sw/lib/llvm/include
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libdir
/sw/lib/llvm/lib
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cppflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-common
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cxxflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual
bash-3.2$ /sw/lib/llvm/bin/llvm-config --ldflags
-L/sw/lib/llvm/lib -lpthread -lm
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libs
-lLLVMLinker -lLLVMipo -lLLVMInterpreter -lLLVMInstrumentation -lLLVMJIT -lLLVMExecutionEngine -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMX86Info -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAsmParser -lLLVMArchive -lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libnames
libLLVMLinker.a libLLVMipo.a libLLVMInterpreter.a libLLVMInstrumentation.a libLLVMJIT.a libLLVMExecutionEngine.a libLLVMBitWriter.a libLLVMX86Disassembler.a libLLVMX86AsmParser.a libLLVMMCParser.a libLLVMX86AsmPrinter.a libLLVMX86CodeGen.a libLLVMSelectionDAG.a libLLVMX86Info.a libLLVMAsmPrinter.a libLLVMCodeGen.a libLLVMScalarOpts.a libLLVMInstCombine.a libLLVMTransformUtils.a libLLVMipa.a libLLVMAsmParser.a libLLVMArchive.a libLLVMBitReader.a libLLVMAnalysis.a libLLVMTarget.a libLLVMMC.a libLLVMCore.a libLLVMSupport.a libLLVMSystem.a
bash-3.2$ /sw/lib/llvm/bin/llvm-config --components
all analysis archive asmparser asmprinter backend bitreader bitwriter codegen core engine executionengine instcombine instrumentation interpreter ipa ipo jit linker mc mcparser native nativecodegen scalaropts selectiondag support system target transformutils x86 x86asmparser x86asmprinter x86codegen x86disassembler x86info
bash-3.2$ /sw/lib/llvm/bin/llvm-config --targets-built
x86
bash-3.2$ /sw/lib/llvm/bin/llvm-config --host-target
x86_64-apple-darwin10.3.0
bash-3.2$ /sw/lib/llvm/bin/llvm-config --build-mode
Release

Out of those, actually the --src-root and --obj-root mess up and
output...

bash-3.2$ /sw/lib/llvm/bin/llvm-config --obj-root
/sw/src/fink.build/llvm-2.7-1/llvm_objdirbash-3.2$

and

bash-3.2$ /sw/lib/llvm/bin/llvm-config --src-root
/sw/src/fink.build/llvm-2.7-1/llvm-2.7bash-3.2$

with a missing newline after the output. It seems that
dragonegg gets confused by the fact that llvm actually
installs the headers in...

/sw/lib/llvm/include/llvm

and

/sw/lib/llvm/include/llvm-c

rather than directly into /sw/lib/llvm/include.
                                      Jack

   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 --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only

Since the gcc45 package installs symlinks to the compilers
in /sw/bin as gcc-4, g++-4, etc, I executed...

GCC=/sw/bin/gcc-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

This fails with...

g++ -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual /Users/howarth/llvm_svn/dragonegg/utils/target.cpp
<command-line>: error: "__STDC_LIMIT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
<command-line>: error: "__STDC_CONSTANT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
make: *** [target.o] Error 1

with GCC apparently being insufficent to redirect the compilers. Instead, I had to use...

GCC=/sw/bin/gcc-4 CC=/sw/bin/gcc-4 CXX=/sw/bin/g++-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

This however fails with...

/sw/bin/gcc-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=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -I/Users/howarth/llvm_svn/dragonegg/x86 -I/Users/howarth/llvm_svn/dragonegg/darwin -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-common /Users/howarth/llvm_svn/dragonegg/llvm-cache.c
In file included from /Users/howarth/llvm_svn/dragonegg/llvm-cache.c:28:0:
/Users/howarth/llvm_svn/dragonegg/llvm-cache.h:31:20: fatal error: config.h: No such file or directory
compilation terminated.
make: *** [llvm-cache.o] Error 1

If I manually run /sw/lib/llvm/bin/llvm-config, I get...

bash-3.2$ /sw/lib/llvm/bin/llvm-config --prefix
/sw/lib/llvm
bash-3.2$ /sw/lib/llvm/bin/llvm-config --src-root
/sw/src/fink.build/llvm-2.7-1/llvm-2.7
bash-3.2$ /sw/lib/llvm/bin/llvm-config --obj-root
/sw/src/fink.build/llvm-2.7-1/llvm_objdir
bash-3.2$ /sw/lib/llvm/bin/llvm-config --bindir
/sw/lib/llvm/bin
bash-3.2$ /sw/lib/llvm/bin/llvm-config --includedir
/sw/lib/llvm/include
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libdir
/sw/lib/llvm/lib
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cppflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-common
bash-3.2$ /sw/lib/llvm/bin/llvm-config --cxxflags
-I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual
bash-3.2$ /sw/lib/llvm/bin/llvm-config --ldflags
-L/sw/lib/llvm/lib -lpthread -lm
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libs
-lLLVMLinker -lLLVMipo -lLLVMInterpreter -lLLVMInstrumentation -lLLVMJIT -lLLVMExecutionEngine -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMX86Info -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAsmParser -lLLVMArchive -lLLVMBitReader -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem
bash-3.2$ /sw/lib/llvm/bin/llvm-config --libnames
libLLVMLinker.a libLLVMipo.a libLLVMInterpreter.a libLLVMInstrumentation.a libLLVMJIT.a libLLVMExecutionEngine.a libLLVMBitWriter.a libLLVMX86Disassembler.a libLLVMX86AsmParser.a libLLVMMCParser.a libLLVMX86AsmPrinter.a libLLVMX86CodeGen.a libLLVMSelectionDAG.a libLLVMX86Info.a libLLVMAsmPrinter.a libLLVMCodeGen.a libLLVMScalarOpts.a libLLVMInstCombine.a libLLVMTransformUtils.a libLLVMipa.a libLLVMAsmParser.a libLLVMArchive.a libLLVMBitReader.a libLLVMAnalysis.a libLLVMTarget.a libLLVMMC.a libLLVMCore.a libLLVMSupport.a libLLVMSystem.a
bash-3.2$ /sw/lib/llvm/bin/llvm-config --components
all analysis archive asmparser asmprinter backend bitreader bitwriter codegen core engine executionengine instcombine instrumentation interpreter ipa ipo jit linker mc mcparser native nativecodegen scalaropts selectiondag support system target transformutils x86 x86asmparser x86asmprinter x86codegen x86disassembler x86info
bash-3.2$ /sw/lib/llvm/bin/llvm-config --targets-built
x86
bash-3.2$ /sw/lib/llvm/bin/llvm-config --host-target
x86_64-apple-darwin10.3.0
bash-3.2$ /sw/lib/llvm/bin/llvm-config --build-mode
Release

Out of those, actually the --src-root and --obj-root mess up and
output...

bash-3.2$ /sw/lib/llvm/bin/llvm-config --obj-root
/sw/src/fink.build/llvm-2.7-1/llvm_objdirbash-3.2$

and

bash-3.2$ /sw/lib/llvm/bin/llvm-config --src-root
/sw/src/fink.build/llvm-2.7-1/llvm-2.7bash-3.2$

with a missing newline after the output. It seems that
dragonegg gets confused by the fact that llvm actually
installs the headers in...

/sw/lib/llvm/include/llvm

and

/sw/lib/llvm/include/llvm-c

rather than directly into /sw/lib/llvm/include.
                                      Jack

If I compare how my llvm-gcc42 package builds against
the llvm package files, I find...

g++ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -pedantic -Wno-long-long -Wno-variadic-macros -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -frandom-seed=0 -DNDEBUG -I. -I. -I../../llvm-gcc4.2-2.7.source/gcc -I../../llvm-gcc4.2-2.7.source/gcc/. -I../../llvm-gcc4.2-2.7.source/gcc/../include -I../../llvm-gcc4.2-2.7.source/gcc/../libcpp/include -I/sw/include -I../../llvm-gcc4.2-2.7.source/gcc/../libdecnumber -I../libdecnumber -I/sw/lib/llvm/include -I/sw/include -DENABLE_LLVM -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I. -I. -I../../llvm-gcc4.2-2.7.source/gcc -I../../llvm-gcc4.2-2.7.source/gcc/. -I../../llvm-gcc4.2-2.7.source/gcc/../include -I../../llvm-gcc4.2-2.7.source/gcc/../libcpp/include -I/sw/include -I../../llvm-gcc4.2-2.7.source/gcc/../libdecnumber -I../libdecnumber -I/sw/lib/llvm/include ../../llvm-gcc4.2-2.7.source/gcc/llvm-main.cpp -o llvm-main.o

where in ../../llvm-gcc4.2-2.7.source/gcc/llvm-main.cpp, we have...

#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/PrettyStackTrace.h"

Shouldn't dragonegg be doing the same...providing
explicit paths from what 'llvm-config --includedir'
returns? Where exactly are some of these headers supposed
to be coming from in llvm-cache.h?

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "target.h"
#include "tree.h"

Shouldn't some of these have explicit paths like...

#include "llvm/Config/config.h"

or

#include "llvm/Target/target.h"

as is the case in llvm-gcc4.2?
               Jack

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

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 --with-ld=/Developer/usr/bin/ld --with-nm=/Developer/usr/bin/nm --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only

Since the gcc45 package installs symlinks to the compilers
in /sw/bin as gcc-4, g++-4, etc, I executed...

GCC=/sw/bin/gcc-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

This fails with...

g++ -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual /Users/howarth/llvm_svn/dragonegg/utils/target.cpp
<command-line>: error: "__STDC_LIMIT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
<command-line>: error: "__STDC_CONSTANT_MACROS" redefined
<command-line>: error: this is the location of the previous definition
make: *** [target.o] Error 1

with GCC apparently being insufficent to redirect the compilers. Instead, I had to use...

GCC=/sw/bin/gcc-4 CC=/sw/bin/gcc-4 CXX=/sw/bin/g++-4 LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make

That's correct. There is no need to build dragonegg with gcc-4.5; gcc-4.5 is
the target of the plugin, which is different. You inform the makefile that the
plugin is for gcc-4.5 using "GCC=...", and as usual you say what compiler to use
to build dragonegg using CC/CXX.

This however fails with...

/sw/bin/gcc-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=\"100909M\" -DTARGET_NAME=\"x86_64-apple-darwin10.3.0\" -I/Users/howarth/llvm_svn/dragonegg -Iplugin/include -I/Users/howarth/llvm_svn/dragonegg/x86 -I/Users/howarth/llvm_svn/dragonegg/darwin -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-common /Users/howarth/llvm_svn/dragonegg/llvm-cache.c
In file included from /Users/howarth/llvm_svn/dragonegg/llvm-cache.c:28:0:
/Users/howarth/llvm_svn/dragonegg/llvm-cache.h:31:20: fatal error: config.h: No such file or directory

This is a gcc-4.5 "plugin header file". You can ask gcc where to find these by
doing:

   /sw/bin/gcc-4 -print-file-name=plugin

On my machine this returns

   /usr/local/gnat-fsf/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin

I suspect that your gcc-4.5 was built without plugin support, and that
because of this you aren't getting a path here.

If I manually run /sw/lib/llvm/bin/llvm-config, I get...

These aren't llvm headers, so llvm-config is not relevant here.

Ciao,

Duncan.

Duncan,
   The following hack to gcc/configure.ac will allow the --enable-plugin option to build and pass
the plugin tests on x86_64-apple-darwin10 using gcc-4_5-branch...

--- configure.ac.orig 2010-04-10 10:58:34.000000000 -0500
+++ configure.ac 2010-04-10 10:59:52.000000000 -0500
@@ -4380,22 +4380,6 @@

pluginlibs=
if test x"$enable_plugin" = x"yes"; then

After editing the dragonegg Makefile to remove -Werror, installing
r100954 of llvm/clang (to /opt/llv, being too lazy to type the 'm'),
copying the missing darwin-sections.def to the installed gcc-4.5.0
release-candidate, as you noticed, I could add /opt/llv/bin to my path
and the path to my gcc-4.5 install, and do:

GCC=/sw/lib/gcc4.5/bin/gcc make CPPFLAGS="-DENABLE_LTO -I/sw/include"

And it worked until the final link, which failed (-shared works in
recent gcc, but is just an alias for -dynamiclib, and doesn't allow
undefined symbols). I copy & pasted the link line, added -undefined
dynamic_lookup, and it linked and apparently works:

mini:dragonegg pogma$ gcc hello.c -S -O1 -o - -fplugin=./dragonegg.so
-fplugin-arg-dragonegg-emit-ir
; ModuleID = 'hello.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-apple-darwin10.3.0"

%"char[]" = type [6 x i8]

@.str = private constant %"char[]" c"Hello\00", align 1 ; <%"char[]"*>
[#uses=2]

define i32 @main() nounwind {
entry:
  %0 = tail call i32 @puts(i8* getelementptr inbounds (%"char[]"* @.str,
i64 0, i64 0)) nounwind ; <i32> [#uses=0]
  ret i32 undef
}

declare i32 @puts(i8* nocapture) nounwind

Pretty awesome!

Peter

>
> 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 -I/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include -I/Users/howarth/llvm_svn/dragonegg/x86 -I/Users/howarth/llvm_svn/dragonegg/darwin -I/sw/include -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual /Users/howarth/llvm_svn/dragonegg/llvm-convert.cpp
> In file included from /Users/howarth/llvm_svn/dragonegg/llvm-convert.cpp:88:0:
> /Users/howarth/llvm_svn/dragonegg/llvm-debug.h:150:3: error: ‘DIFile’ does not name a type

After editing the dragonegg Makefile to remove -Werror, installing
r100954 of llvm/clang (to /opt/llv, being too lazy to type the 'm'),
copying the missing darwin-sections.def to the installed gcc-4.5.0
release-candidate, as you noticed, I could add /opt/llv/bin to my path
and the path to my gcc-4.5 install, and do:

GCC=/sw/lib/gcc4.5/bin/gcc make CPPFLAGS="-DENABLE_LTO -I/sw/include"

And it worked until the final link, which failed (-shared works in
recent gcc, but is just an alias for -dynamiclib, and doesn't allow
undefined symbols). I copy & pasted the link line, added -undefined
dynamic_lookup, and it linked and apparently works:

mini:dragonegg pogma$ gcc hello.c -S -O1 -o - -fplugin=./dragonegg.so
-fplugin-arg-dragonegg-emit-ir
; ModuleID = 'hello.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-apple-darwin10.3.0"

%"char[]" = type [6 x i8]

@.str = private constant %"char[]" c"Hello\00", align 1 ; <%"char[]"*>
[#uses=2]

define i32 @main() nounwind {
entry:
  %0 = tail call i32 @puts(i8* getelementptr inbounds (%"char[]"* @.str,
i64 0, i64 0)) nounwind ; <i32> [#uses=0]
  ret i32 undef
}

declare i32 @puts(i8* nocapture) nounwind

Pretty awesome!

Peter

Peter,
    I am going to post this to gcc-patches after
regression testing on gcc-4_5-branch.
               Jack

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 14%
on llvm-gfortran over the past 13 months without the
llvm developers even targeting those. With a modern
gfortran and decent vectorization support, the benchmarks
could be quite interesting and might fire up some interest
among the FSF gcc developers.
         Jack

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 -I/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include -I/Users/howarth/llvm_svn/dragonegg/x86 -I/Users/howarth/llvm_svn/dragonegg/darwin -I/sw/include -Wall -Werror -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual /Users/howarth/llvm_svn/dragonegg/llvm-convert.cpp
In file included from /Users/howarth/llvm_svn/dragonegg/llvm-convert.cpp:88:0:
/Users/howarth/llvm_svn/dragonegg/llvm-debug.h:150:3: error: ‘DIFile’ does not name a type
make: *** [llvm-convert.o] Error 1

where /sw/bin/gcc-4 is the gcc 4.5.0 from my gcc45 fink package
with plugin support. Do you see this under linux?

are you building against LLVM top-of-tree? Currently dragonegg needs gcc
from svn, and the same for LLVM. It would make sense to have versions of
dragonegg that target:
   (1) Latest gcc release, latest LLVM release (this is not relevant until
gcc-4.5 is released)
   (2) Latest gcc release, LLVM from svn (this is not relevant until gcc-4.5
is released)
   (3) Latest LLVM release, gcc from svn
   (4) gcc from svn, LLVM from svn
Currently I'm only doing (4). Once gcc-4.5 is released I may do (4) and (2).
I don't plan to do (1) or (3) unless I get some help.

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.

Hi Jack,

    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 14%
on llvm-gfortran over the past 13 months without the
llvm developers even targeting those. With a modern
gfortran and decent vectorization support, the benchmarks
could be quite interesting and might fire up some interest
among the FSF gcc developers.

my impression is that Fortran is a bit less stable with dragonegg as
compared to llvm-gcc, probably because llvm-gcc was patched to remove
some Fortran bogosities that are still present in gcc mainline. That
said, it can still compile a lot of Fortran.

Ciao,

Duncan.

Duncan,
   Yes, I was trying to use dragon-egg svn with llvm release-2.7 branch (because
I was in the process of preparing llvm/llvm-gcc42 2.7 fink packages and had
those handy). I'll try again with llvm svn. FYI, I have posted the --enable-plugin
fix patch for darwin to the gcc-patches mailing list...

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00516.html

I think we need one more darwin-specific FSF gcc patch for dragon-egg
(as gcc 4.5.0 doesn't installed the required darwin-sections.def into
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config).
I am still pondering how to properly do that in the Makefiles.
  Have any prior dragon-egg gcc patches been committed and do you intend
to post the i386_static.diff to gcc-patches?
              Jack
ps I did notice the dragon-egg web page said that exception handling was
broken but I did see some recent commits on that feature. What is the
status of exception handling in current svn?

Hi Jack,

    Yes, I was trying to use dragon-egg svn with llvm release-2.7 branch (because
I was in the process of preparing llvm/llvm-gcc42 2.7 fink packages and had
those handy). I'll try again with llvm svn. FYI, I have posted the --enable-plugin
fix patch for darwin to the gcc-patches mailing list...

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00516.html

yes I saw it - thanks for doing this. Unfortunately I'm not competent to review
it.

I think we need one more darwin-specific FSF gcc patch for dragon-egg
(as gcc 4.5.0 doesn't installed the required darwin-sections.def into
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config).
I am still pondering how to properly do that in the Makefiles.
   Have any prior dragon-egg gcc patches been committed and do you intend
to post the i386_static.diff to gcc-patches?

Several dragonegg gcc patches have been previously committed. I don't plan to
push i386_static.diff to gcc though, because (1) I think I can do without it
(though this will require quite a lot of work), and (2) I'm trying to avoid
pushing patches to gcc if they are only useful to dragonegg.

               Jack
ps I did notice the dragon-egg web page said that exception handling was
broken but I did see some recent commits on that feature. What is the
status of exception handling in current svn?

It is almost finished, and I expect it to be completely finished next week
sometime. You will probably find that exception handling already works fine.
Currently things may go wrong in obscure circumstances at high optimization
levels. The other problem is that if a C++ destructor throws an exception,
then std::terminate may not always be called.

Ciao,

Duncan.

That's nicer! Thank you.

Why not do this too?

Peter

dash_bundle.patch (718 Bytes)

Hi Peter,

Why not do this too?

can this be extracted out of llvm-config somehow?

Ciao,

Duncan.

Hi,

Doesn't look like llvm-config has this info.

Peter

> 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,
   On a different issue, when you built dragon-egg,
did you manually copy darwin-sections.def into
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config?
Do you have any idea how we can achieve this in the Makefiles
without being platform specific or installing too many additional
files there? Thanks in advance for any hints.
        Jack

Peter,
   Does this still work for you with current llvm svn? I created a new llvm
fink package from current svn and used that to build the current dragon-egg
against my gcc45 package with plugin support enabled. The build of the plugin
worked but when I try to use it I get..

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
  Referenced from: /Users/howarth/llvm_svn/dragonegg/dragonegg.so
  Expected in: flat namespace
in /Users/howarth/llvm_svn/dragonegg/dragonegg.so

I noticed that I have...

bash-3.2$ otool -L ./dragonegg.so
./dragonegg.so:
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

in both builds I tried...

GCC=/sw/lib/gcc4.5/bin/gcc LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make CPPFLAGS="-DENABLE_LTO -I/sw/include"

and

GCC=/sw/lib/gcc4.5/bin/gcc LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config CC=gcc-4 CCX=g++-4 LDFLAGS=-L/sw/lib make CPPFLAGS="-DENABLE_LTO -I/sw/include"

How do you build llvm? I am using...

Info2: <<
Package: llvm
Version: 2.799
Revision: 101114
#Source: http://llvm.org/releases/%v/llvm-%v.tar.gz
Source: http://llvm.org/releases/%v/llvm-2.8.tar.gz
Source-MD5: d317d277e97c3852994bb4dcaadf1591
SourceDirectory: llvm-2.8
Type: -64bit .
Architecture: x86_64
BuildDepends: fink (>= 0.28)
ConfigureParams: <<
--prefix=%p/lib/llvm --mandir=%p/share/man --infodir=%p/share/info --with-gmp=%p --with-libiconv-prefix=/usr --with-system-zlib --with-as=`xcode-select -print-path`/usr/bin/as --with-ld=`xcode-select -print-path`/usr/bin/ld --with-nm=`xcode-select -print-path`/usr/bin/nm
<<
CompileScript: <<
#!/bin/bash -ev
export LD=`xcode-select -print-path`/usr/bin/ld
ulimit -s `ulimit -s`
mkdir ../llvm_objdir
cd ../llvm_objdir
# ../llvm-%v/configure %c --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only
../llvm-2.8/configure %c --enable-optimized --enable-assertions --enable-pic --enable-targets=host-only
num_cpu=$(echo `sysctl -n hw.ncpu`)
make -j $num_cpu
<<
InstallScript: <<
#!/bin/sh -ev
export LD=`xcode-select -print-path`/usr/bin/ld
cd ../llvm_objdir
make install DESTDIR=%d
mkdir -p %i/bin
ln -s %p/lib/llvm/bin/bugpoint %i/bin/bugpoint
ln -s %p/lib/llvm/bin/gccas %i/bin/gccas
ln -s %p/lib/llvm/bin/gccld %i/bin/gccld
ln -s %p/lib/llvm/bin/llc %i/bin/llc
ln -s %p/lib/llvm/bin/lli %i/bin/lli
ln -s %p/lib/llvm/bin/llvm-ar %i/bin/llvm-ar
ln -s %p/lib/llvm/bin/llvm-as %i/bin/llvm-as
ln -s %p/lib/llvm/bin/llvm-bcanalyzer %i/bin/llvm-bcanalyzer
ln -s %p/lib/llvm/bin/llvm-config %i/bin/llvm-config
ln -s %p/lib/llvm/bin/llvm-db %i/bin/llvm-db
ln -s %p/lib/llvm/bin/llvm-dis %i/bin/llvm-dis
ln -s %p/lib/llvm/bin/llvm-extract %i/bin/llvm-extract
ln -s %p/lib/llvm/bin/llvm-ld %i/bin/llvm-ld
ln -s %p/lib/llvm/bin/llvm-link %i/bin/llvm-link
ln -s %p/lib/llvm/bin/llvm-nm %i/bin/llvm-nm
ln -s %p/lib/llvm/bin/llvm-prof %i/bin/llvm-prof
ln -s %p/lib/llvm/bin/llvm-ranlib %i/bin/llvm-ranlib
ln -s %p/lib/llvm/bin/llvm-stub %i/bin/llvm-stub
ln -s %p/lib/llvm/bin/llvmc %i/bin/llvmc
ln -s %p/lib/llvm/bin/opt %i/bin/opt
<<
SplitOff: <<
  Package: %N-shlibs
  Files: <<
     lib/llvm/lib/libEnhancedDisassembly.dylib
     lib/llvm/lib/libLLVMHello.dylib
     lib/llvm/lib/libprofile_rt.dylib
     lib/llvm/lib/libLTO.dylib
  <<
  Shlibs: <<
     !%p/lib/llvm/lib/libEnhancedDisassembly.dylib
     !%p/lib/llvm/lib/libLLVMHello.dylib
     !%p/lib/llvm/lib/libprofile_rt.dylib
     %p/lib/llvm/lib/libLTO.dylib 0.0.0 %n (>= 2.7-1) 64
  <<
<<
License: GPL
Description: Low Level Virtual Machine Compiler
DescDetail: <<
A compilation strategy designed to enable effective program optimization across
the entire lifetime of a program. LLVM supports effective optimization at
compile time, link-time (particularly interprocedural), run-time and offline
(i.e., after software is installed), while remaining transparent to developers
and maintaining compatibility with existing build scripts.
<<
DescPackaging: <<
The file libLTO.dylib in %p/lib/llvm/lib can be used to replace the libLTO.dylib
in /Developer/usr/lib from Xcode 3.1.2 to enable full LTO support at -O4 in
the compilers of the llvm-gcc42 package. Note that the fink maintainer mode
doesn't understand the @executable_path/../lib/libLTO.dylib syntax in libLTO.dylib's
otool -L output.
<<
Homepage: http://llvm.org/
Maintainer: None <fink-devel@lists.sourceforge.net>
<<

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,

Why not do this too?

I've applied this - thanks for the patch!

Ciao,

Duncan.

Duncan,
   Yes. I had dropped that patch since the last time I tried to
build with it my machine had a kernel panic. I was puzzled by
that patch since it seems to be declaring the type_natural_mode(),
classify_argument(), examine_argument() and contains_aligned_value_p()
as extern while leaving the original subroutines declared in
gcc/config/i386/i386.c. Doesn't extern imply that the code resides
outside that source file? From...

http://wiki.answers.com/Q/What_is_the_use_of_extern_in_C

I see "An extern is something that is defined externally to the current module."
so aren't we invoking undefined behavior or something like that? We
seem to both be saying these are defined externally while still
defining them locally.
                    Jack