Re: [RFA:] fix breakage with "Update testsuite to run with slim LTO"

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Oct 21, 2011 at 1:56 PM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Iain Sandoe <developer@sandoe-acoustics.co.uk> writes:
>
>> It looks like the gnat testsuite is also broken - but HP's fix doesn't
>> recover that.
>> .. will try and take a look - but short on time today,
>
> I think I see what's going on: in gnat.log, I find
>
> Running /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/dg.exp ...
> ERROR: tcl error sourcing library file /vol/gcc/src/hg/trunk/local/gcc/testsuite/lib/gcc-dg.exp.
> can't read "GCC_UNDER_TEST": no such variable
> can't read "GCC_UNDER_TEST": no such variable
> ? ?while executing
> "lappend options "compiler=$GCC_UNDER_TEST""
> ? ?(procedure "gcc_target_compile" line 37)
> ? ?invoked from within
> "gcc_target_compile $source $dest $type $options"
> ? ?invoked from within
> "if [ string match "*.c" $source ] then {
> ? ? ? ?return [gcc_target_compile $source $dest $type $options]
> ? ?}"
> ? ?(procedure "gnat_target_compile" line 12)
> ? ?invoked from within
> "${tool}_target_compile $src $output $compile_type "$options""
> ? ?(procedure "check_compile" line 39)
> ? ?invoked from within
> "check_compile linker_plugin executable {
> ? ? int main() { return 0; }
> ?} {-flto -fuse-linker-plugin}"
> ? ?("eval" body line 1)
> ? ?invoked from within
> "eval check_compile $args"
> ? ?(procedure "check_no_compiler_messages_nocache" line 2)
> ? ?invoked from within
> "check_no_compiler_messages_nocache linker_plugin executable {
> ? ? int main() { return 0; }
> ?} "-flto -fuse-linker-plugin""
> ? ?(procedure "check_linker_plugin_available" line 2)
> ? ?invoked from within
> "check_linker_plugin_available"
> ? ?invoked from within
> "if [check_effective_target_lto] {
> ? ?# When having plugin test both slim and fat LTO and plugin/nonplugin
> ? ?# path.
> ? ?if [check_linker_plugin_ava..."
> ? ?(file "/vol/gcc/src/hg/trunk/local/gcc/testsuite/lib/gcc-dg.exp" line 71)
> ? ?invoked from within
> "source /vol/gcc/src/hg/trunk/local/gcc/testsuite/lib/gcc-dg.exp"
> ? ?("uplevel" body line 1)
> ? ?invoked from within
> "uplevel #0 source /vol/gcc/src/hg/trunk/local/gcc/testsuite/lib/gcc-dg.exp"
>
> If running the gnat.dg testsuite, lib/gcc-dg.exp is now calling
> check_linker_plugin_available early, which ultimately calls
> ${tool}_target_compile. ?For all languages but Ada,
> ${tool}_target_compile can compile .c files just fine, but
> gnat_target_compile (which uses gnatmake) cannot, so it falls back to
> directly calling gcc_target_compile in that case. ?gcc_target_compile
> relies on GCC_UNDER_TEST being set, which in this case hasn't yet
> happened, thus the error.
>
> My solution (a hack, actually) is to move the initialization of
> GCC_UNDER_TEST in gcc-dg.exp before the calls to
> check_linker_plugin_available. ?x86_64-unknown-linux-gnu testing in
> progress, will commit once that's finished.
>
> Btw., the ChangeLog entry for Jan's patch was riddled with typos and
> wrong pathnames. ?I've corrected that with a separate checkin.

Still doesn't work for me:

rguenther@murzim:/abuild/rguenther/trunk-g/gcc> make check-gfortran
RUNTESTFLAGS="dg.exp=logical_dot_product.f90"
...
Running /space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/dg.exp ...
ERROR: (DejaGnu) proc "gcc_target_compile linker_plugin14146.o
linker_plugin14146 executable { additional_flags=-flto
additional_flags=-flto-partition=none additional_flags=-save-temps }"
does not exist.
The error code is NONE
The info on the error is:
close: spawn id exp6 not open
    while executing
"close -i exp6"
    invoked from within
"catch "close -i $spawn_id""

This is highly annoying for me ... (reverting Rainers patch doesn't help).

Richard.