[patch] migrating DragonEgg to DIBuilder

David Blaikie dblaikie at gmail.com
Wed Feb 20 11:06:23 PST 2013


On Wed, Feb 20, 2013 at 12:44 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi David,
>
>  Hmm, I'll have to admit to having only run the GDB 7.5 test suite, not the
>> DragonEgg tests.
>>
>> Trying now, I get this error:
>>
>> aking DragonEgg 'test/dragonegg-lit.site.cfg' file...
>> sed: file lit.tmp line 3: unknown option to `s'
>> make: *** [test/dragonegg-lit.site.cfg] Error 1
>>
>
> what is in lit.tmp?  Line 3 is generated by the Makefile like this:
>
>         $(QUIET)echo s=@GCC_LANGUAGES@=$(GCC_**LANGUAGES)=g >> lit.tmp
>
> Presumably GCC_LANGUAGES is wrong.  Maybe multi-line?  It is created as
> follows:
>
> GCC_LANGUAGES=$(shell $(GCC) -v 2>&1 | grep '^Configured with:' | sed
> 's/^.*--enable-languages=\([^ ]*\).*/\1/')
>
> What does "gcc -v" output on your system.


 $HOME/install/bin/gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=/usr/local/google/home/blaikie/install/bin/gcc-4.7
COLLECT_LTO_WRAPPER=/usr/local/google/home/blaikie/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure
--prefix=/usr/local/google/home/blaikie/install --program-suffix=-4.7
--disable-checking
Thread model: posix
gcc version 4.7.2 (GCC)

Guess I configured GCC too simply?


>
>
>
>> do you have any idea about that?
>>
>> (running "make check-validator" again produces a different error:
>>
>
> When sed fails it leaves an empty test/dragonegg-lit.site.cfg file, while
> it
> shouldn't leave any file at all.  I've fixed this.  Now it should fail the
> same
> way (as above) no matter how many times you run it!
>

Looks like it does - thanks for that.

- David


>
> Ciao, Duncan.
>
>  For the record, I'm running this like:
>>
>> GCC=$HOME/install/bin/gcc-4.7 CC=$HOME/dev/llvm/install/**
>> clang/debug/bin/clang
>> CXX=$HOME/dev/llvm/install/**clang/debug/bin/clang++  make
>> check-validator
>>
>>
>>     - some Fortran testcases crash, but it's not your fault: it occurs
>> with
>>     pointers to arrays, due to hitting this:
>>
>>        if (isa<ARRAY_TYPE>(type) && TYPE_STRING_FLAG(type) &&
>>            isa<INTEGER_TYPE>(TREE_TYPE(__**type))) {
>>
>>          DEBUGASSERT(0 && "Don't support pascal strings");
>>          return DIType();
>>        }
>>
>>     Then the empty DIType is used by the pointer code to try and form a
>>     derived type.  I'm not sure why this (ancient) debug code thinks there
>>     is a problem with this kind of array, so I will try to fix it to
>> handle
>>     them properly.
>>
>>
>> Thanks muchly,
>>
>> - David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130220/9a34ef3c/attachment.html>


More information about the llvm-commits mailing list