DragonEgg for gcc-5 and llvm-3.6

Project Infrastructure LLVM Dev List Archives
1

Hi,

My brother (Tarun) and I have been attempting to get dragonegg working with gcc-5 and llvm-3.6. So far we have had some success and most of the compilator and validator tests of dragonegg pass. However the following validator tests fail and we don’t understand why.

The Validator :: c++/2007-01-06-ELF-Thunk-Sections.cpp
The Validator :: c/ExternFunctionWeakref.c
The Validator :: c/ExternVariableWeakref.c
The Validator :: c/InternFunctionWeakref.c
The Validator :: c/InternVariableWeakref.c

Since the last four are extremely similar, I give the example of ExternVariableWeakref.c below:

The test file looks like:

// RUN: %dragonegg -S %s -o - | FileCheck %s
static int variable_weakref attribute ((weakref(“bar”)));
int use_variable = &variable_weakref;
// CHECK: @use_variable = unnamed_addr global i32 @bar
// CHECK: @bar = extern_weak global i32

And the output we get (which ideally should match the CHECK sections above) is:

@use_variable = unnamed_addr global i32* @variable_weakref
@variable_weakref = internal global i32 0

Note that for some reason, it is not creating a weak symbol.

We’d appreciate any suggestions on how these might be fixed or where to look to figure out what’s going on.

Thanks and Regards,
Arun Prabhu

2

Thanks very much for working on Dragonegg. I don’t have an answer for your specific problem, but there has been discussion on the topic of the LLVM licensing agreement that seems to be considering dropping Dragonegg, I’m not sure if you are aware of this?

Dragonegg is the only method currently available to LLVM for incorporating FORTRAN numeric libraries into the set of targets that LLVM has code generators for, and while there are licensing issues to be careful of, the ability to import high quality mature FORTRAN libraries is very valuable to the LLVM community. I think that the LLVM community needs to be aware of the utility of this particular project. A huge amount of high quality, mature and robust HPC and numerical computing is currently only available through FORTRAN despite attempts to create C versions of BLAS, LAPACK, FFT3 and others. But C suffers from aliasing issues that are hard to resolve, and the existing FORTRAN implementations of many libraries is only accessible to LLVM via the Dragonegg project.

Thanks again Arun & Tarun,

MartinO

3

Hi Arun,

Hi,

My brother (Tarun) and I have been attempting to get dragonegg working with
gcc-5 and llvm-3.6. So far we have had some success and most of the compilator
and validator tests of dragonegg pass. However the following validator tests
fail and we don't understand why.

     The Validator :: c++/2007-01-06-ELF-Thunk-Sections.cpp
     The Validator :: c/ExternFunctionWeakref.c
     The Validator :: c/ExternVariableWeakref.c
     The Validator :: c/InternFunctionWeakref.c
     The Validator :: c/InternVariableWeakref.c

Since the last four are extremely similar, I give the example of
ExternVariableWeakref.c below:

The test file looks like:

// RUN: %dragonegg -S %s -o - | FileCheck %s
static int variable_weakref __attribute__ ((weakref("bar")));
int *use_variable = &variable_weakref;
// CHECK: @use_variable = unnamed_addr global i32* @bar
// CHECK: @bar = extern_weak global i32

And the output we get (which ideally should match the CHECK sections above) is:

@use_variable = unnamed_addr global i32* @variable_weakref
@variable_weakref = internal global i32 0

Note that for some reason, it is not creating a weak symbol.

We'd appreciate any suggestions on how these might be fixed or where to look to
figure out what's going on.

it's great to hear that you are trying to bring dragonegg back to life. The logic for weak symbols has broken several times in the past when changing GCC versions. That's because the way weak symbols were represented inside GCC used to be a mess, and GCC has been evolving towards a more sane system. Much more like LLVM's in fact. Unfortunately for dragonegg, each step in that evolution tends to break the logic. My guess is that they made a new step. Take a look in emit_alias in Backend.cpp for the dragonegg logic. You may want to try asking on the GCC IRC channel for help understanding what has changed in the GCC handling of weak symbols.

Ciao, Duncan.

4

Dragonegg appears to be licensed under GPLv2-or-later, as old GCC was. (Or maybe it has incorporated GPLv3-or-later code from newer GCC versions into it too, making it actually GPLv3-or-later now). In either case, there'd be no license issue, as GPLv3 *is* compatible with the proposed switch of LLVM to the Apache2 license.

So I believe there should be no problem there.