llvm dev - Oct 2015 - DragonEgg for gcc-5 and llvm-3.6

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151028/a27c990a/attachment.html>

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

 

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Arun
Prabhu via llvm-dev
Sent: 28 October 2015 12:43
To: llvm-dev at lists.llvm.org
Cc: Tarun Prabhu <tarunprabhu at gmail.com>
Subject: [llvm-dev] DragonEgg for gcc-5 and llvm-3.6

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151028/5a00fd66/attachment.html>

Hi Arun,

On 28/10/15 13:42, Arun Prabhu via llvm-dev wrote:
> 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.

>
> Thanks and Regards,
> Arun Prabhu
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On Oct 28, 2015, at 11:52 AM, Martin J. O'Riordan via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 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 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.