DragonEgg 3.0 with GCC 4.7

Project Infrastructure LLVM Dev List Archives
1

I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works fine. However, I can't submit that to the repository.

On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an error compiling Backend.cpp, but yesterday I saw that commit #152558 fixes this. However, now when I try to build DragonEgg, I get a lot of other errors.

On the one hand, I don't expect there to be any official support for DragonEgg 3.0 with GCC 4.7. On the other hand, it would be nice to get DragonEgg into Fedora 17 rather than having to wait another six months for LLVM 3.1 to land in Fedora 18. Would anyone care to look at the build problems I'm seeing? Perhaps these problems were already fixed in other commits in the repository.

Some of the errors I'm getting are:

/builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp: In function 'uint64_t getFieldOffsetInBits(tree)':
/builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp:191:56: error: 'BITS_PER_UNIT' was not declared in this scope

/builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp: In member function 'void DefaultABI::HandleArgument(tree, std::vector<llvm::Type*, std::allocator<llvm::Type*> >&, llvm::Attributes*)':
/builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp:223:14: error: 'TARGET_64BIT' was not declared in this scope
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm_p.h:5:0,
                  from /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:52:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:13: error: use of enum 'reg_class' without previous declaration
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:68: error: invalid type in declaration before ';' token
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ExtendRange(SignedRange, llvm::TargetFolder&) const':
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:188:7: error: 'BYTES_BIG_ENDIAN' was not declared in this scope
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ReduceRange(SignedRange, llvm::TargetFolder&) const':

The full build log is at:
     http://koji.fedoraproject.org/koji/getfile?taskID=3925063&name=build.log

Once i can get DragonEgg into Fedora, I'm hoping to convince the package maintainers for GCC in Red Hat Enterprise Linux 6 to include the patch to GCC 4.4 necessary to build DragonEgg 2.8, since I expect it will be a long time (years!) before LLVM 3.x shows up in RHEL7.

Thanks!
Eric

2

I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has
LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build
LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works
fine. However, I can't submit that to the repository.

On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and
GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an
error compiling Backend.cpp, but yesterday I saw that commit #152558
fixes this. However, now when I try to build DragonEgg, I get a lot of
other errors.

On the one hand, I don't expect there to be any official support for
DragonEgg 3.0 with GCC 4.7. On the other hand, it would be nice to get
DragonEgg into Fedora 17 rather than having to wait another six months
for LLVM 3.1 to land in Fedora 18. Would anyone care to look at the
build problems I'm seeing? Perhaps these problems were already fixed in
other commits in the repository.

   At r153413, the dragonegg compilation errors against gcc-4.7.0 using
clang is...

Compiling Constants.cpp
/sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp:1594:24: error: no member named 'same_body' in 'cgraph_node'
    for (alias = node->same_body; alias && alias->next; alias = alias->next) ;
                 ~~~~ ^
1 error generated.

and using gcc-4.7.0 itself...

Compiling Constants.cpp
/sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp: In function 'void emit_aliases(cgraph_node_set, varpool_node_set)':
/sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp:1594:24: error: 'struct cgraph_node' has no member named 'same_body'
make: *** [Backend.o] Error 1

Hopefully this is the last compilation error blocking dragonegg on gcc 4.7.0.
           Jack
ps This was from testing on x86_64-apple-darwin11.

3

Hi Eric,

I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has
LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build
LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works
fine. However, I can't submit that to the repository.

On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and
GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an
error compiling Backend.cpp, but yesterday I saw that commit #152558
fixes this.

it was a warning not an error, but perhaps you build with -Werror?

   However, now when I try to build DragonEgg, I get a lot of

other errors.

I've started porting dragonegg to gcc-4.7 (I fixed a few things this weekend
already). The same-body alias implementation changed substantially it seems,
and I also see a lot of compile failures in Convert.cpp related to
synchronization primitives, probably coming from the GCC changes made to
support C++-11 atomics. These two will require time, thought and care to
update right. ABIHack.inc is also failing to compile, but this looks
to be a mild problem.

That said, getting it compiling is not the same as having it work well, or even
work at all. For example, if gcc-4.7 is bootstrapped then it compiles itself
using the first-stage C++ compiler which means that all names are mangled, while
if gcc-4.7 is not bootstrapped then names are not mangled because it is compiled
as C. Currently dragonegg expects names to not be mangled, but it will somehow
have to detect gcc's with mangled names otherwise it will fail miserably.

Ciao, Duncan.

4

Duncan Sands wrote:
> That said, getting it compiling is not the same as having it work well, or even work at all.

OK, it sounds like I'd best just wait for you to finish getting it working with GCC 4.7. If that makes it into 3.1, then I might be able to get a DragonEgg 3.1 package into Fedora 18, toward the end of this year. Assuming that Fedora hasn't already moved to GCC 4.8 by then. :slight_smile:

Thanks!
Eric