LLVM test-suite support for dragonegg / Fortran

Project Infrastructure LLVM Dev List Archives
1

Hi,

I am very interested in using dragonegg as a fortran frontend for the LLVM test suite, as a start to improve fortran support.

I believe this should be easy, but when I looked into this I had the impression the nightly tester in the llvm test-suite does not even support dragonegg for the C/C++ part. Is this true or did I miss something?

Are there any patches flying around, that would take care of this? How is dragonegg regression tested? Is the llvm test-suite used or something else?

Cheers
Tobi

2

Hi Tobias,

I am very interested in using dragonegg as a fortran frontend for the LLVM test
suite, as a start to improve fortran support.

I believe this should be easy, but when I looked into this I had the impression
the nightly tester in the llvm test-suite does not even support dragonegg for
the C/C++ part. Is this true or did I miss something?

this is true.

Are there any patches flying around, that would take care of this? How is
dragonegg regression tested? Is the llvm test-suite used or something else?

I have my own testsuite (which I should really clean up and make public) and
from time to time I run a hacked version of the LLVM testsuite, see the
attached patch. It would be great to get proper support in the testsuite.
I always meant to set up a dragonegg nightly tester but never got around
to it...

Ciao,

Duncan.

de.diff (3.6 KB)

3

Hi Duncan,

I committed an extended version of that patch to llvm core and the test suite. Can you have a look, if it works for you.

Thanks
Tobi

4

Hi Tobias,

I committed an extended version of that patch to llvm core and the test suite.
Can you have a look, if it works for you.

if I configure like this then the configure script thinks llvm-gcc is not
dragonegg:

configure --with-llvmgcc="gcc-4.5 -fplugin=path/dragonegg.so" --with-llvmgxx="g++-4.5 -fplugin=path/dragonegg.so"

There are several reasons for this. First off, the test
   if test -x "$LLVMGCC" ; then
fails because "g++-4.5 -fplugin=path/dragonegg.so" is indeed not an executable.
This test is redundant, since you are about to execute the program on the next
lines, which will fail anyway. Suppose this test is eliminated. It still fails
because

   "$LLVMGCC" -fplugin-arg-dragonegg-emit-ir -S -o - conftest.c

won't execute, because "$LLVMGCC" is not an executable. This can be cured by
removing the quotation marks. This suggests the following patch, what do you
think? I'm worried that this is the wrong approach. If it is the right
approach, probably the testsuite configure files will need to be tweaked too.

Ciao,

Duncan.

--- configure (revision 118890)
+++ configure (working copy)
@@ -20569,16 +20569,14 @@
    echo $ECHO_N "(cached) $ECHO_C" >&6
  else
    llvm_cv_llvmgcc_dragonegg="no"
-if test -x "$LLVMGCC" ; then
    cp /dev/null conftest.c
- "$LLVMGCC" -fplugin-arg-dragonegg-emit-ir -S -o - conftest.c | \
+ $LLVMGCC -fplugin-arg-dragonegg-emit-ir -S -o - conftest.c | \
    grep 'target datalayout =' > /dev/null 2>&1
    if test $? -eq 0 ; then
      llvm_cv_llvmgcc_dragonegg="yes"
    fi
    rm conftest.c
  fi
-fi
  { echo "$as_me:$LINENO: result: $llvm_cv_llvmgcc_dragonegg" >&5
  echo "${ECHO_T}$llvm_cv_llvmgcc_dragonegg" >&6; }

@@ -20598,32 +20596,30 @@
    echo $ECHO_N "(cached) $ECHO_C" >&6
  else
    llvm_cv_llvmgcc_sanity="no"
-if test -x "$LLVMGCC" ; then
    cp /dev/null conftest.c
- "$LLVMGCC" "$LLVMCC_EMITIR_FLAG" -S -o - conftest.c | \
+ $LLVMGCC "$LLVMCC_EMITIR_FLAG" -S -o - conftest.c | \
        grep 'target datalayout =' > /dev/null 2>&1
    if test $? -eq 0 ; then
      llvm_cv_llvmgcc_sanity="yes"
    fi
    rm conftest.c
  fi
-fi
  { echo "$as_me:$LINENO: result: $llvm_cv_llvmgcc_sanity" >&5
  echo "${ECHO_T}$llvm_cv_llvmgcc_sanity" >&6; }

  if test "$llvm_cv_llvmgcc_sanity" = "yes" ; then
    { echo "$as_me:$LINENO: checking llvm-gcc component support" >&5
  echo $ECHO_N "checking llvm-gcc component support... $ECHO_C" >&6; }
- llvmcc1path=`"$LLVMGCC" --print-prog-name=cc1`
+ llvmcc1path=`$LLVMGCC --print-prog-name=cc1`
    LLVMCC1=$llvmcc1path

- llvmcc1pluspath=`"$LLVMGCC" --print-prog-name=cc1plus`
+ llvmcc1pluspath=`$LLVMGCC --print-prog-name=cc1plus`
    LLVMCC1PLUS=$llvmcc1pluspath

    llvmgccdir=`echo "$llvmcc1path" | sed 's,/libexec/.*,'`
    LLVMGCCDIR=$llvmgccdir

- llvmgcclangs=`"$LLVMGCC" -v --help 2>&1 | grep '^Configured with:' | sed 's/^.*--enable-languages=\([^ ]*\).*/\1/'`
+ llvmgcclangs=`$LLVMGCC -v --help 2>&1 | grep '^Configured with:' | sed 's/^.*--enable-languages=\([^ ]*\).*/\1/'`
    LLVMGCC_LANGS=$llvmgcclangs

    LLVMGCC_DRAGONEGG=$llvm_cv_llvmgcc_dragonegg

5

Hi Duncan,

I have used the dragonegg installed by ubuntu. It uses a script installed as llvm-gcc, which just adds "-fplugin=path/dragonegg.so" to the arguments and than calls gcc.

I am not sure which is the best approach to support not just a binary, but a binary with arguments for LLVMGCC. I am a little bit worried that there may be more places that expect LLVMGCC to be a binary.

However, as I do not see any problems arising from this patch, I am fine with it. It is needed if we want dragonegg support for LLVMGCC without the use of a separate script.

I propose to wait a day to see, if anybody else can see a problem.

Cheers
Tobi

6

Hi Tobias,

I have used the dragonegg installed by ubuntu. It uses a script installed as
llvm-gcc, which just adds "-fplugin=path/dragonegg.so" to the arguments and than
calls gcc.

I think it is best to keep things simple for the moment, as close to the usual
non-dragonegg case as possible. I think I will add such an llvm-gcc script to
the dragonegg repository, and use it for testing for the time being.

Ciao,

Duncan.