On x86_64-unknown-linux-gnu, revision 149190: make -k check-gcc RUNTESTFLAGS="plugin.exp" results in Running gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp ... ERROR: tcl error sourcing gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp. ERROR: can't read "ld_library_path": no such variable while executing "set value $ld_library_path" (procedure "set_ld_library_path_env_vars" line 47) invoked from within "set_ld_library_path_env_vars" (procedure "plugin-test-execute" line 32) invoked from within "plugin-test-execute $plugin_src $plugin_input_tests" ("foreach" body line 13) invoked from within "foreach plugin_test $plugin_test_list { # Replace each source file with its full-path name for {set i 0} {$i < [llength $plugin_test]} {incr i..." (file "/usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp" line 56) invoked from within "source /usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp" invoked from within "catch "uplevel #0 source $test_file_name"" Similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40601, http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01099.html may be the cause.
Created attachment 18126 [details] Proposed Patch
Running /Users/apinski/src/local/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... ERROR: tcl error sourcing /Users/apinski/src/local/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp. Looks like the same issue too.
I can reproduce the error with plugin.exp not struct-layout-1.exp. This fixes it for me, does it for you guys? Index: gcc/testsuite/lib/gcc.exp =================================================================== --- gcc/testsuite/lib/gcc.exp (revision 149287) +++ gcc/testsuite/lib/gcc.exp (working copy) @@ -96,6 +96,7 @@ proc gcc_init { args } { global TOOL_EXECUTABLE global gcc_warning_prefix global gcc_error_prefix + global ld_library_path if { $gcc_initialized == 1 } { return; } @@ -113,6 +114,7 @@ proc gcc_init { args } { set gcc_warning_prefix "warning:" set gcc_error_prefix "error:" + set ld_library_path "" gcc_maybe_build_wrapper "${tmpdir}/gcc-testglue.o" }
Subject: Re: [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp" Your fix works for me.
Setting to P4 on the basis that the described bug circumstances involve a RUNTESTFLAGS setting to use a single .exp file, please restore to P3 if it appears without using any RUNTESTFLAGS setting.
This works for me, does it work for you now?
According to comment #6 this works now. Can the OP please confirm?
GCC 4.5.0 is being released. Deferring to 4.5.1.
GCC 4.5.1 is being released, adjusting target milestone.
GCC 4.5.2 is being released, adjusting target milestone.
I still see the struct-layout-1.exp error. Running /var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/gcc/testsuite/g++.dg/compat/struct-layout-1.exp ... ERROR: tcl error sourcing /var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/gcc/testsuite/g++.dg/compat/struct-layout-1.exp. ERROR: can't read "HOSTCC": no such variable while executing "remote_exec build "$HOSTCC $HOSTCFLAGS $generator_cmd"" invoked from within "set status [remote_exec build "$HOSTCC $HOSTCFLAGS $generator_cmd"]" (file "/var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/gcc/testsuite/g++.dg/compat/struct-layout-1.exp" line 134) invoked from within "source /var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/gcc/testsuite/g++.dg/compat/struct-layout-1.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/gcc/testsuite/g++.dg/compat/struct-layout-1.exp" invoked from within "catch "uplevel #0 source $test_file_name""
GCC 4.5.3 is being released, adjusting target milestone.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
The original bug in this report was fixed back in the summer of 2009 almost immediately after this bug was reported. THe was a follow-on issue reported (c#11) which was unfortunately tacked onto this report. I have been unable to reproduce the issue noted in c#11, even if I go back to the gcc-4.5 branchpoint. While the follow-on issue looks similar, it would be a distinct problem. I'm closing as the original issue is resolved and has been for a very long time. If the secondary issue is still a problem, a new bug should be filed.