Message ID | 20160602121905.GE28550@tucnak.redhat.com |
---|---|
State | New |
Headers | show |
On 06/02/2016 02:19 PM, Jakub Jelinek wrote: > The problem is that in cleanup-after-saved-dg-test, there are missing global > directives, so when it tests/uses the set_compiler_env_var and > saved_compiler_env_var vars to see if it should call > restore-compiler-env-var, it uses local (non-existing) vars instead and > never restores the env var. I'm puzzled how failing to restore the env var causes a failure, but your patch is (obviously) ok. Bernd
On Thu, Jun 02, 2016 at 02:26:28PM +0200, Bernd Schmidt wrote: > On 06/02/2016 02:19 PM, Jakub Jelinek wrote: > >The problem is that in cleanup-after-saved-dg-test, there are missing global > >directives, so when it tests/uses the set_compiler_env_var and > >saved_compiler_env_var vars to see if it should call > >restore-compiler-env-var, it uses local (non-existing) vars instead and > >never restores the env var. > > I'm puzzled how failing to restore the env var causes a failure, but your > patch is (obviously) ok. The second of the tests using the new dg-set-compiler-env-var directive is doing /* { dg-set-compiler-env-var SOURCE_DATE_EPOCH "AAA" } */ and then expecting an error. If the env var isn't restored, then on any of the following testcases that uses __DATE__ and similar macros the env var contains still AAA and thus results in an error. Jakub
--- gcc/testsuite/lib/gcc-dg.exp.jj 2016-06-01 19:16:51.000000000 +0200 +++ gcc/testsuite/lib/gcc-dg.exp 2016-06-02 11:56:54.429137894 +0200 @@ -895,6 +895,8 @@ if { [info procs saved-dg-test] == [list global shouldfail global testname_with_flags global set_target_env_var + global set_compiler_env_var + global saved_compiler_env_var global keep_saved_temps_suffixes global multiline_expected_outputs